必须为可能为NULL的Oracle VARCHAR2字段显式声明jdbcType=VARCHAR，因MyBatis自动推断不可靠，否则触发ORA-00932类型不匹配错误；XML中写#{field,jdbcType=VARCHAR}，注解方式需改用XML或设默认空字符串。
MyBatis 插入 NULL 到 Oracle VARCHAR2 字段报 ORA-00932 错误
oracle 对空值（null）的 jdbc 类型推断很敏感，尤其当 mybatis 没显式指定 jdbctype 时，驱动可能把 null 当作 other 或 unknown 类型传入，而 oracle 要求明确知道该列是 varchar2 才能接受 null。典型错误是：ora-00932: inconsistent datatypes: expected varchar2 got blob 或类似类型不匹配提示。
根本原因不是字段本身不能存 null，而是 JDBC 驱动在绑定参数时没拿到足够类型信息，导致 Oracle 内部做了错误类型映射。
- 必须为所有可能为
null的VARCHAR2参数显式声明jdbcType=VARCHAR - 不要依赖 MyBatis 的自动类型推断（尤其 Oracle 场景下基本不可靠）
-
jdbcType=VARCHAR是 Oracle 兼容性最稳的选择；jdbcType=CHAR或jdbcType=NVARCHAR在某些驱动版本下反而会触发隐式转换失败 - 如果用的是 MyBatis 3.4+，
jdbcType必须写全大写：VARCHAR，小写varchar会被忽略
XML 映射中怎么加 jdbcType=VARCHAR
在 <insert></insert> 或 <update></update> 的 <parametermap></parametermap>（已废弃）或更常见的 <bind></bind>/#{} 占位符里补全类型声明。
错误写法：#{userName} —— 无 jdbcType，NULL 时大概率崩
正确写法：#{userName,jdbcType=VARCHAR}
- 只对可能为
null的字符串字段加，非空字段可省略 - 若字段是
CLOB，对应用jdbcType=CLOB；但VARCHAR2(4000)一律用VARCHAR，别用LONGVARCHAR（Oracle 不认） - 批量插入时，每个
#{xxx}都要单独加，不能在<foreach></foreach>外统一设 - 如果用了
@SelectKey或自定义 typeHandler，仍需确保其返回值也带jdbcType声明
使用 @Options 注解或 @Insert 时如何指定 jdbcType
注解方式没法直接写 jdbcType，MyBatis 的 @Insert、@Update 不支持在占位符里嵌套语法。这时候得绕道：
- 改用 XML 映射 —— 最稳妥，类型控制粒度最细
- 或在实体类字段上加
@Param+ 自定义TypeHandler，但成本高，仅适合全局统一规则场景 - 如果坚持用注解，可在
#{}外围包一层IF判断（如<if test="userName != null">#{userName,jdbcType=VARCHAR}</if>），但会导致 SQL 动态拼接变复杂，且NULL字段无法插入 - 更现实的做法：把关键字符串字段默认值设为空字符串
""，而非null，再配合数据库DEFAULT ''约束 —— 这样既避开jdbcType问题，又保持语义清晰
为什么用 jdbcType=VARCHAR 而不是其他？
Oracle 的 JDBC 驱动对 jdbcType 的映射有硬编码逻辑：VARCHAR 明确映射到 Types.VARCHAR，最终转成 VARCHAR2；而 CHAR 会走固定长度路径，LONGVARCHAR 可能被当成 CLOB 处理，OTHER 则直接触发类型歧义。
-
jdbcType=VARCHAR是 Oracle 官方 JDBC 文档推荐用于VARCHAR2的标准值 - MyBatis 内部对
VARCHAR的处理最成熟，和StringTypeHandler绑定最紧 - 某些老版本 Oracle 驱动（如 ojdbc6）遇到
jdbcType=NVARCHAR会抛ORA-01461，即使字段是NVARCHAR2 - 别迷信“自动识别”——Oracle 不像 MySQL 那样宽容，类型声明不是可选项，是必填项
真正麻烦的从来不是写那几个字母，而是有人在十几层 service 调用后，把一个 null 字符串一路透传进 mapper，却忘了最外层那个 jdbcType=VARCHAR。漏掉一次，就可能卡住整条流水线。
