Mybatis疑难事件簿：‘#‘传递布尔值无效问题_mybatis布尔值为什么不能用#-CSDN博客

博客探讨了在使用Mybatis-Plus时遇到的布尔值作为条件在'#{}'中无效的问题。通过打印执行SQL和尝试使用'${}'替换'#{}'，发现预编译过程导致了问题，因为Mybatis将布尔值转换为'1'或'0'。解决方案是避免使用'#{}'，而是使用'${}'进行布尔值的传递。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、问题现场

MySQL自5.7版本就开始提供JSON类型，本次问题就是在使用JSON类型时出现的MySQL服务可以正常查询而使用Mybatis查询失效问题。

具体表现为在使用Mybatis（这里需要注意一下，笔者实际使用了其增强版Mybatis-Plus）按照JSON类型字段中某个key的指定value进行条件查询时出现无法查询出结果，在参数值传递时使用了'#'进行变量值传递，查询代码如下：

    @Select("select * from `task_info` where task_params -> #{fieldName} = #{fieldValue}")
    @ResultMap("mybatis-plus_TaskInfo")
    List<TaskInfo> selectByTaskParams(String fieldName, Object fieldValue);
复制代码

经过测试可以发现，上述查询语句只有在针对布尔类型变量传递时才会发生查询失效的情况，当传递的参数为字符串类型和数字类型时是能够正常查询出结果。

二、探寻症结

1. 打印执行SQL

在发现Mybatis的执行结果和直接运行SQL的执行结果不一致后，最初的猜测是Mybatis实际执行的SQL和目标SQL不一致，导致最终执行结果和预期结果不一致。为了验证猜想，需要将Mybatis中实际执行的SQL打印出来进行对比判断，这里引入了p6spy开源工具来进行数据库操作的跟踪（这里没有使用StdOutImpl的原因是因为在控制台打印时，执行SQL并没有做到拼接处理，对应的参数仍然是以'?'展示）。

通过上面的工具可以在控制台中看到实际的执行SQL如下：

select * FROM `task_info` WHERE task_params -> '$.online' = true;
复制代码