记一个挺有趣的 关于mybatis in入参的bug排查

这个bug其实主要不在于写出来多奇怪

主要是排查的时候觉得蛮有趣的.

是一段17年遗留的老代码里面的.

最开始代码运行并未出现报错之类的. 只是某条20多个入参, 将近300多行的sql查询结果一直是0条记录.

但是使用传入的参数手动搜索是有查询结果的.

其实再idea控制台查看入参的时候,有个奇怪的小细节, 只是当时没注意, 不然就没有后面的事了.

idea显示的入参中间有两个参数显示是 '10100', '10400'(String) 用idea的控制台显示sql语句的param的时候, 会在每个参数后面用括号写出参数类型,唯独这个10100后面没有带类型, 而且idea控制台的param如果是string类型是不会'贴心'地加上单引号的. 况且, string类型加单引号很奇怪吧, Java的习惯单引号是字符, 此处应该是双引号才对.

但是当时的我没有注意到, 傻乎乎地以为这是两个简单的String入参.

于是, 我打开了Mybatis Log Plugin复制粘贴进数据库连接工具, 执行.

报错???en(此处应有第三声)???

查看报错信息, 将sql语句粘贴进txt, ctrl+f查找(实在太长orz), 发现 in("'10100','10400'")

哦豁?

再回头仔细一看, 很贴心的 10100和10400两个字符串被两头变成了一个"'10100','10400'"的字符串, 单引号和双引号是代码里面硬加上去的, 然后这个命运多舛的String--XXXCode被简单粗暴地塞进了in(#{XXXCode}).

orz, 请收下我的膝盖

作为接手的人, 排查真的不容易

题外话, 附上正确做法

传个List<String>

使用mybatis的foreach去遍历

in 
<foreach item="XXXCodeItem" index="index" collection="XXXCode" open="(" separator="," close=")">
   #{XXXCodeItem,jdbcType=VARCHAR}
</foreach>