首先#{} 和 ${} 都是参数占位符，其中#{}是预编译处理，${}是字符直接进行替换。预编译处理是指：MyBatis 在处理#{}时，会将 SQL 中的 #{} 替换为?号，使⽤ PreparedStatement 的 set ⽅法来赋值。直接替换是指MyBatis 在处理 ${} 时，就是把 ${} 替换成变量的值。

其中#{}与JDBC中的PreparedStatement的作用类似，都可以防止sql注入问题。

但是在单表查询中，他们都可能会带来越权查询和操作数据等问题。下面详细列出实例：

使用#{}得到JDBC的代码如下:【针对int类型的参数】

使用${}得到JDBC的代码如下:【针对int类型的参数】 

 使用${}得到JDBC的代码如下:【针对String类型的参数】

不难看出这个时候sql语法报错了。

使用#{}得到JDBC的代码如下:【针对String类型的参数】

到这里我们就已经可以看出来一些区别了：

1.定义不同: #{}是预处理;而${}是直接替换。

2.使用不同: #{}适用于所有类型的参数匹配;但${}只适用数值类型。

3.安全性不同: #{}性能高，因为他使用占位符已经预编译了，并且没有安全问题; 但${}存在SQL注入的安全问题（下面会给出示例）。

那再谈谈#{}和${}的各自使用场景：

1.${}的使用场景：（对数据进行排序的时候）

但是如果此时使用#{}就会报sql语法错误，因为此时需要传递的是SQL关键字。 

到这里咱们又可以对#{}和${}做一个小结：

当传递的是一个SQI.关键字（SQI命令）的时候，只能使用${}，此时如果使用#{}就会认为传递的为一个普通的值，而非SQL命令，他在替换的时候会自动加上’’号，所以执行就会报错。

接下来咱们继续说说刚才在上面总结的那样，${}存在SQL注入的安全问题。

咱们在实现用户登录功能这个场景下，通常需要获取用户名和密码来校验是否正确，那么这个时候就会出现问题，我们先来正常的查询：

再继续看SQL注入的有安全问题： 

 

在sql语法中，1=’1’是正确的，所以这条sql语句也是可以执行的。所以当不得不使用$时，那么一定要在业务代码中，对传递的值进行安全效验。 

最后再看看like查询这种场景。

使用#{}:

但是使用${}就可以了： 

但是使用${}还是有安全风险，因为模拟查询的时候，不知道用户传来的是什么数据，我们也不能一一穷举出来去规避，那么此时使用#{}的时候还有一种方法可以避免安全问题：