MyBatis Integer类型参数动态SQL判断陷阱与修复

核心问题：Integer类型的0值被误判

在开发中，我们常使用实体类传递参数，其中包含status、sort等Integer类型的字段。当这些字段值为0时，如果在MyBatis的动态SQL中使用常规的判空逻辑，往往会导致查询条件丢失。这是因为MyBatis底层使用的OGNL表达式引擎，会将数字0自动转换或解析为空字符串''。这一特性对于String类型参数适用，但对于Integer参数则会产生误导。

第1步：识别错误的代码写法

许多开发者习惯性地沿用String类型的判空模板，即同时检查null和空字符串。例如以下常见的错误拼写：

<if test="work_status !=null  and work_status !='' ">
  and T.status=#{work_status,jdbcType=INTEGER}
</if>

在此代码中，当传入的work_status值为整数0时，OGNL将其视为空字符串，导致work_status != ''的判断结果为false。最终，整个<if>块不生效，数据库查询中遗漏了状态筛选条件，造成数据异常。

第2步：应用正确的判空逻辑

针对Integer、Long等数值型参数，无需也不应进行空字符串判断。只需要保留对null的检查即可。修正后的代码如下：

<if test="work_status !=null  ">
  and T.status=#{work_status,jdbcType=INTEGER}
</if>

同理，如果是通过Bean对象传递的参数（如bean.activitySort），也应摒弃对空字符串的判断：

<if test="bean.activitySort != null">
    AND activity_sort = #{bean.activitySort,jdbcType=VARCHAR}
</if>

尽管此处指定了jdbcType为VARCHAR，但如果传入的是Integer类型的0，同样的解析陷阱依然存在。因此，无论目标字段类型如何，只要传参变量本身是包装类型（如Integer），且需要兼容0值，都应严格只使用!= null作为条件。

总结

在使用MyBatis进行动态SQL构建时，务必区分数据类型的语义。对于Integer等非字符串基本类型的包装类，避免使用!= ''进行校验，仅依赖!= null即可确保0值被正确处理。以上就是MyBatis处理Integer参数动态SQL条件判断的详细技巧，更多关于MyBatis高级用法的资料请关注本站其它相关文章！