xxl-job报错 a different jdbcTypeForNull confiquration property

这个错误是 XXL-Job 在执行 MyBatis SQL 操作时出现的参数绑定问题，具体原因是 MyBatis 无法处理 null 参数的 JDBC 类型，导致 SQLException: invalid column type: 1111（1111 是 JdbcType.OTHER 的内部编码）。

错误分析

1. 核心问题：

   • MyBatis 在执行 SQL 时，某个参数（glueSource）被设置为 null，但没有明确指定 jdbcType。
   • 默认情况下，MyBatis 会尝试推断 null 的 JDBC 类型，但某些数据库驱动（如 PostgreSQL、Oracle）对 null 的类型要求严格，导致 invalid column type 错误。

2. 关键错误信息：

   Could not set parameters for mapping: ParameterMapping{property='glueSource', ...}
   Error setting null for parameter #15 with JdbcType OTHER
   SQLException: invalid column type: 1111
   

   • glueSource 参数是 String 类型，但传入的是 null。
   • MyBatis 默认使用 JdbcType.OTHER 处理 null，但数据库驱动不支持。

解决方案

方法 1：修改 MyBatis 配置，全局设置 jdbcTypeForNull

在 application.properties 或 application.yml 中配置：

# application.properties
mybatis.configuration.jdbc-type-for-null=NULL

或

# application.yml
mybatis:
  configuration:
    jdbc-type-for-null: NULL

这样 MyBatis 会将 null 显式设置为 JdbcType.NULL，而不是 OTHER。

方法 2：在 Mapper XML 中显式指定 jdbcType

如果 glueSource 是 XXL-Job 的某个 SQL 参数（比如 XxlJobInfo 或 XxlJobGlue 表的字段），在对应的 Mapper XML 文件中修改：

<!-- 示例：修改 glueSource 参数的 jdbcType -->
<insert id="save" parameterType="XxlJobInfo">
    INSERT INTO xxl_job_info (..., glue_source, ...)
    VALUES (..., #{glueSource,jdbcType=VARCHAR}, ...)
</insert>

关键点：

• 显式指定 jdbcType=VARCHAR（或其他合适的类型，如 CLOB）。

方法 3：检查数据库表结构

1. 确认 xxl_job_info 或 xxl_job_glue 表中 glue_source 字段的类型：

   • 如果是 TEXT、CLOB 或 VARCHAR，确保 MyBatis 映射的 javaType 和 jdbcType 匹配。
   • 如果字段允许 NULL，但代码传入了 null，需按 方法 1 或 2 处理。

2. 示例表结构（MySQL）：

   CREATE TABLE xxl_job_info (
       ...
       glue_source VARCHAR(2000) NULL COMMENT 'GLUE脚本内容',
       ...
   );
   

方法 4：检查 XXL-Job 版本

• 如果是旧版 XXL-Job，可能存在 MyBatis 映射配置问题，尝试升级到最新稳定版。

根本原因

• MyBatis 默认对 null 参数使用 JdbcType.OTHER，但某些数据库驱动（如 PostgreSQL）不支持该类型。
• XXL-Job 的某些 SQL 操作（如保存或更新 Job 信息时）未正确处理 glueSource 参数的 null 值。

总结

1. 推荐优先使用方法 1（全局配置 jdbcTypeForNull），简单高效。
2. 如果问题仅出现在特定 SQL，使用方法 2（显式指定 jdbcType）。
3. 检查数据库表结构和 XXL-Job 版本，确保兼容性。

修改后重启服务，问题应该能解决。如果仍有异常，可以检查 XXL-Job 的日志，定位具体的 SQL 语句。