Mybatis疑难事件簿：#‘传递布尔值无效问题

最新推荐文章于 2024-02-18 13:54:56 发布

敲代码的程序狗

最新推荐文章于 2024-02-18 13:54:56 发布

阅读量893

点赞数 1

文章标签： sql mysql 数据库

本文链接：https://blog.csdn.net/weixin_57907028/article/details/122602042

版权

本文详述了一起在Mybatis（Mybatis-Plus）中使用JSON类型字段查询时，遇到的布尔值传递无效问题。通过打印执行SQL和替换占位符，发现使用'#{}'预编译过程导致问题，而'${}'则能正常工作。问题根源在于PreparedStatement在设置布尔参数时，会将其转换为0或1，与期望的true/false不符。最后，总结了'#{}'与'${}'的区别，强调了理解细节的重要性。

摘要由CSDN通过智能技术生成

一、问题现场

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如下&#x