关于工作中Mybatis中的$和#的区别和理解

想起来前几天的工作中，线上突然出现了一个bug，说是什部分数据查询出错。看了看后台日志，也没发现什么情况。

sql原本是这样的

后来我怀疑是Mybatis的$的问题，将它替换成#。替换下来果然bug解决了。所以决定记录一下，不能白白的踩这个坑。

这是你可能会奇怪，这两个其实不是差不多嘛。我起始本来也是这么认为的，虽然表面差不多，起始背后的原理则不同。

1、Mybatis中的#{}是预编译处理，Mybatis在处理#{}时，它会将sql中的#{}替换成?，然后调用PreparedStatement的set方法来赋值，传入字符串后，会在值两边加上单引号。

2、Mybatis中的${}是字符串替换，Mybatis在处理${}时，它会将sql中的${}替换成变量的值，传入的数据不会在两边加上单引号。

我们这次传入的值对应的PORT_ID字段是char类型。所以碰见有的数据如果用${}的话，会出现错误，而且用${}会导致sql注入，不利于系统的安全性。

    sql注入：就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将(恶意的)SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击。

对于#和$的应用场合：

   1、#{ }：主要用户获取DAO中的参数数据,在映射文件的SQL语句中出现#{}表达式,底层会创建预编译的SQL；

   2、${ }:主要用于获取配置文件数据,DAO接口中的参数信息,当$出现在映射文件的SQL语句中时创建的不是预编译的SQL,而是字符串的拼接,有可能会导致SQL注入问题.所以一般使用$接收dao参数时,这些参数一般是字段名,表名等,例如order by {column}。

注：${}获取DAO参数数据时,参数必须使用@param注解进行修饰或者使用下标或者参数#{param1}形式。#{}获取DAO参数数据时,假如参数个数多于一个可有选择的使用@param。