问题描述

提前剧透：
如果参数中有. ?等特殊参数，需要使用${}，但需要注意sql注入问题

@Select("select * from account order by #{orderBy} #{orderRule} limit #{start},#{offset}")
public List<Account> getAccountList(@Param("orderBy") String orderBy, @Param("orderRule") String orderRule,@Param("start) int start, @Param("offset") int offset);

如上代码所示，在执行查询操作时，为了能够与前端联动进行排序，直接在SQL参数中传递排序字段和排序规则。
但是，在调试时偶然发现，当传递的“orderBy”值为不存在的字段时，竟然不会报错！！！
经过进一步调试发现，实际上并不会按照预期的排序规则返回数据列表！！！

原因分析

设置log4j的日志级别为DEBUG后发现，最终执行的SQL语句是一个预编译操作，mybatis输出日志如下：

==> Preparing: select * from account order by ? ? limit ?, ?
==> Parameters: loginName(String), DESC(String), 0(Integer), 50(Integer)
很显然，传递的参数loginName和DESC是作为字符串处理的。
也就是说，很有可能mybatis对String类型的参数会进行转换。举个例子：传递的String参数为loginName，最终在SQL语句执行时为：‘loginName’。
再进一步验证，如果在SQL语句中传递的排序字段不是字段名loginName，而是’loginName’时，是不会按照排序规则返回数据的，并且也不会报错！
追溯mybatis官方文档发现：默认情况下,使用#{}格式的语法会导致mybatis对字符串进行修改或转义！！！

字符串替换

解决问题
将参数传递的语法格式#{}修改为${}，即：

@Select("select * from account order by ${orderBy} ${orderRule} limit #{start},#{offset}")
public List<Account> getAccountList(@Param("orderBy") String orderBy, @Param("orderRule") String orderRule,@Param("start) int start, @Param("offset") int offset);

总结

此时，对于使用${}格式引用的参数，mybatis直接在SQL语句中插入一个不改变的字符串，而不再作为一个预编译参数处理。
注意： 以这种方式接收用户输入的内容并直接提供给SQL语句作为不变的字符串是不安全的，会导致潜在的SQL注入攻击，因此要么不允许用户输入这些字段，要么自行转义并检验。