出现奇怪的bug,那就从头来过,不要漏掉任何地方!
#{}
与${}
的区别
#{}
是预编译处理,${}
是字符串替换Mybatis在处理#{}时,会将sql中的#{}替换为?号, 调用PreparedStatement的set方法来赋值;
Mybatis在处理${}时,就是把${}替换成变量的值。
使用#{}可以有效的防止SQL注入,提高系统安全性。
再通俗的说,使用${}
mybatis会把参数加上双引号,而${}
你给啥,sql语句中就是啥,如下示例:
1 | select * from table where name = #{name} name->小明 |
问题
最近有个功能需要从sqlserver中去数据,有个脚本很简单如下:
1 | select * from table where id in(...) |
id已经创建索引了,考虑到数据传输,我每次设置的集合大小为100个,因为这是再简单不过的语句了,直接上线给别人使用,但是别人的反馈是,使用50个id需要40多秒!!! 这就有点吓人了,幸好此场景只是在半夜定时的去使用,慢一点不会对第二天有影响,但是白天想要测试的时候就懵了。当然了40多s就别提是否影响别人使用了,基本上就已经崩溃了好不好!!!
这就有点吓人了,幸好此场景只是在半夜定时的去使用,慢一点不会对第二天有影响,但是白天想要测试的时候就懵了。当然了40多s就别提是否影响别人使用了,基本上就已经崩溃了好不好!!!
下面简化了一下,对应的xml代码如下:
1 | <select id="selectTbdIdByLbdIdList" resultType="xxx.xxx.xxMapper"> |
debug 模式下的输出如下:
1 | | ==> Preparing: SELECT id ,tid FROM table where id IN ( ?,?,?,?,?,?...) |
我把sql整理出来放在sqlserver客户端去执行
1 | SELECT id ,tid FROM table where id IN ( "123","234","345"...); |
刚开始执行报错了,后面把双引号改成单引号就行了,即
1 | SELECT id ,tid FROM table where id IN ( '123','234','345'...); |
记住这里的单双引号的问题
??? 很快啊,这是什么情况,第一次遇到这种情况,直接运行sql很快,但是通过mybatis就很慢。
所以我首先怀疑是ORM
框架的问题,接着我用JDBC
快速写了个demo,来验证,代码如下:
1 | String connectionUrl = "jdbc:sqlserver://xxx:8838;DatabaseName=xxx;user=xxx;password=xx"; |
这里也是很快,没什么问题,忽略ORM
的问题。
因为我这里用的是Mybatis-Plus
,所以我又怀疑是mp的问题,于是debug代码,最后卡在这个地方:
1 | //PreparedStatementHandler.class |
但这是Mybatis
的代码,再者说mp只是简化了代码生成这一块,对Mybatis
本身的执行没有影响,所以mp也被排除!
这个时候已经过去很长时间了,整个人很懵,怎么会这样???这么简单的sql还会出这么大的问题!我重新理了下思绪,此处的sql是在sqlserver上执行的,那会不会是sqlserver上的问题呢?
我突然灵光一闪,刚刚debug出来的脚本直接放在sqlserver的客户端上执行的时候是有问题的,我后面是把双引号改成单引号才成功的,我赶紧调整了xml中的脚本,如下:
1 | <select id="selectTbdIdByLbdIdList" resultType="xxx.xxx.xxMapper"> |
然后再执行,debug出来的脚本如下:
1 | | ==> Preparing: SELECT id ,tid FROM table where id IN ( '123','234','345','456'...) |
耗时: 0.100s!!!!
如释重负,原来是双引号惹的祸!
SqlServer是不支持双引号的,但是mybatis最后生成的sql使用的双引号,当然这对mysql是没问题的,当然也有例外
如果SQL服务器模式启用了NSI_QUOTES,可以只用单引号引用字符串。用双引号引用的字符串被解释为一个识别符。
所以我遇到的情况是就是生成带双引号的脚本丢给sqlserver执行的时候,被sql服务器误认为是一个识别符,类似java中类型的强转,此时索引是不生效的,也就是说一开的in查询时没有使用到索引的!!!话说那个表中有700w条记录,怪不得每次查询50条的时候,耗时很均匀,都在40多秒。。。。。
回到开头,这种情况就是借助${}
来解决,当然是用它是有隐患的,因为它并不能防止sql注入,但是对于我这边的场景不会出现这种情况,所以我赶紧的把其他地方也都改了过来!!!
最后
解决问题还是要大胆假设,小心求证 事实的真相只有一个!!!
另外在debug的时候,顺便看到了#{}
和${}
的拼接代码,放在了下面
1 | // ForEachSqlNode |
1 | // TextSqlNode |
1 | // GenericTokenParser |