mybatis中${}的sql注入解决方案
主要解决sql的like 、in 、order by 注入问题，其他查询也可以参照下面解决建议
首先#{}和${}在预编译中的处理是不一样的。
#{}在预处理时，会把参数部分用一个占位符 ?代替，变成如下的sql语句：
select * from user where name = ?;
${}则只是简单的字符串替换，在动态解析阶段，该sql语句会被解析成
select * from user where name = 'Seattle';
上面#{}的参数转换是发生在DBMS中，而${}则发生在动态解析过程中的，所以优先使用#{}，这样就可以避免sql解析注入。
下面介绍几种查询避免sql注入的案例
1.模糊查询like的两种修复建议：
select * from user where name like '%${name}%'; /*有注入风险sql*/
处理方式1：在程序中校验并拼接%后，直接用#格式，如下
select * from user where name like #{name}
处理方式2：在xml配置中用sql的内置函数拼接，如下
select * from user where name like concat('%',#{name},'%');
-----------------------------------------------------------------------------------------
2.in查询的注入修复建议
select * from user where id in
<foreach collection="ids" item="item" open="("separator="," close=")">#{item}</foreach>
-----------------------------------------------------------------------------------------
3.order by修复建议
select * from userorder by #{name} desc /*有问题sql*/
因为预编译机制只能处理查询参数，此处显然不是查询参数，需要开发人员自己处理。所以只能这样拼接：
select * from userorder by ${name} desc
针对这种情况研开发人员可以通过程序来进行解决。比如制定一个规则，判断执行此程序时是否需要排序，然后把排序的字段传进来，这样比较简单。
其实也可以在xml中处理，用if去判断，这样就显得比较硬编码，而且sql也增加了不少，不便阅读。我觉得在程序处理好一点。
上面第一个in也可以在程序处理，但是xml处理更直观简单，所以我就没写程序处理建议。
