动态sql是mybatis的主要特性之一。在mapper中定义的参数传到xml中之后,在查询之前mybatis会对其进行动态解析。

mybatis提供了两种支持动态sql的语法：#{} 和 ${}。

select * from t_user where username = '${username}';
select * from t_user where username = #{username};

username传参一致的话,这两种执行的结果是一样的,但是这两种方式在动态sql解析阶段的处理是不一样的。

1、#{}

解析为一个JDBC预编译语句（prepared statement）的参数标记符,把参数部分用占位符 ? 代替。动态解析为:

select * from t_user where username = ?;

而传入的参数将会经过PreparedStatement方法的强制类型检查和安全检查等处理，最后作为一个合法的字符串传入。

2、${}

这种方式只会做简单的字符串替换，在动态SQL解析阶段将会进行变量替换,假如传递的参数为二师兄,最终处理结果如下:

select * from t_user where username = '二师兄' ;

这样在预编译之前的sql语句已经不包含变量了,因此可以看出 ${} 变量的替换阶段是在动态SQL解析阶段。

3、#{}与${}两种方式对比

1）是否预防SQL注入

以上不同的处理方式可以看出

• {} 预处理之后可以预防SQL注入

• ${} 预编译之前就已经被替换,有被注入的风险

举个栗子:

如果传入的username 为 a' or '1=1,那么使用 ${} 处理后直接替换字符串的sql就解析为:

select * from t_user where username = 'a' or '1=1' ;

这样的话所有的用户数据就被查出来了,这样就属于SQL注入.

如果使用#{},经过sql动态解析和预编译,会把单引号转义为 \' 那么sql最终解析为:

select * from t_user where username = "a\' or \'1=1 ";//这样会查不出任何数据，有效阻止sql注入

有的业务场景经常用到模糊查询,也就是like处理,推荐使用以下处理方式:
t_user.username like #username#

if (!StringUtil.isEmpty(this.username)) {
table.setUsername("%" + this.username + "%");
}

或者也可以使用数据库函数进行连接处理:

select * from t_user u where username  like CONCAT('%', #username#, '%')

注意:
以上就可以发现在某些特定场景下只能用${},比如order by后的排序字段,表名、列名,因为需要替换为不变的常量。如果表名中使用#{}的话,会变成如下：
select from #{tablename}-->tablename传参为t_user --->处理后变成 select from 't_user',没有这样的表名,这样的话就会报错了,order by 同理。

2）性能考虑

因为预编译语句对象可以重复利用,把一个sql预编译后产生的PreparedStatement对象缓存下来,下次对于同一个sql，可以直接使用缓存的PreparedStatement对象,mybatis默认情况下,对所有的sql进行预编译,这样的话 #{}的处理方式性能会相对高些。

总结：

能使用#{}的时候尽量使用#{}表名。
order by的排序字段作为变量时,使用${}。

来源：https://dwz.cn/tQwJGPbP
关注微信公众号【悟能之能】了解更多编程技巧。
回复"面经"获取面试资料