🍃前言
MyBatis参数赋值有两种⽅式,使⽤ #{} 和 ${}进⾏赋值,接下来我们看下⼆者的区别
🌳#{}和${}使⽤
我们先来看一下两者在基础数据类型与string类型下的使用
🚩Interger类型的参数（基础数据类型）
🏀使用#{}
代码：
我们观察一下我们的打印日志：
发现我们输出的SQL语句：
select * from userinfo where id = ?
我们输⼊的参数并没有在后⾯拼接，id的值是使⽤ ? 进⾏占位.这种SQL我们称之为"预编译SQL"
🏀使用${}
代码：
观察一下我们的打印日志：
发现我们输出的SQL语句：
select * from userinfo where id = 2
可以看到,这次的参数是直接拼接在SQL语句中了.
🚩String类型的参数
🏀使用#{}
代码：
观察打印日志：
结果与上面一样成功返回
🏀使用${}
代码：
再次进行打印日志：
可以看到,这次的参数依然是直接拼接在SQL语句中了,但是字符串作为参数时,需要添加引号' '，使⽤ ${} 不会拼接引号' '，导致程序报错
修改代码如下：
再次运行
从上⾯两个还例⼦可以简单看出:
#{} 使⽤的是预编译SQL,通过 ? 占位的⽅式,提前对SQL进⾏编译,然后把参数填充到SQL语句中.
#{} 会根据参数类型,⾃动拼接引号' '，把他变成字符串 .${} 会直接进⾏字符替换,⼀起对SQL进⾏编译.如果参数为字符串,需要加上引号 ' '
参数为数字类型时,也可以加上引号,查询结果不变,但是可能会导致索引失效,性能下降
🎍#{}和${}区别
#{}和${}的区别就是预编译SQL和即时SQL的区别.
🚩#{}性能更高
绝⼤多数情况下,某⼀条SQL语句可能会被反复调⽤执⾏,或者每次执⾏的时候只有个别的值不同(⽐如select的where⼦句值同,update的set⼦句值不同,insert的values值不同).
如果每次都需要经过上⾯的语法解析,SQL优化、SQL编译等，则效率就明显不⾏了.
预编译SQL，编译⼀次之后会将编译后的SQL语句缓存起来，后⾯再次执⾏这条语句时，不会再次编译(只是输⼊的参数不同),省去了解析优化等过程,以此来提⾼效率
🚩#{}更安全(防止SQL注入)
存在SQL注入的问题，我们知道，符号是直接拼接的，那么我们在拼接的时候，就可以拼接一些别的信息，不一定是传参
SQL注⼊：是通过操作输⼊的数据来修改事先定义好的SQL语句，以达到执⾏代码对服务器进⾏攻击的⽅法
原因：由于没有对⽤⼾输⼊进⾏充分检查，⽽SQL⼜是拼接⽽成，在⽤⼾输⼊参数时，在参数中添加⼀些SQL关键字，达到改变SQL运⾏结果的⽬的，完成恶意攻击
接下来我们先看一个sql注入的例子：
注入sql代码： ' or 1='1
首先我们有以下代码：
当我们正常传参数时，代码如下：
正常运行结果如下：
接下来我们注入sql代码如下：
再次运行：结果依然被正确查询出来了,其中参数or被当做了SQL语句的⼀部分
但是呢，我们需要查询的应该是一个人的信息，这里却将所有人的信息给打印了出来。
更早期会出现直接删数据,但是这种mybatis不支持
' '; delete from info; -- '
🚩${}的使用场景
从上⾯的例⼦中,可以得出结论:$ {}会有SQL注⼊的⻛险,所以我们尽量使⽤#{}完成查询
既然如此,是不是$ { }就没有存在的必要性了呢?
当然不是.接下来我们看下${}的使⽤场景
🏀排序功能
接下来我们来实现通过传递参数让表实现降序排序：
我们先用#{}
代码：
当我们进行传参：
进行启动：
可以发现,当使⽤ #{order} 查询时,desc前后⾃动给加了引号,导致sql错误
使用${}就可以避免这种情况：
启动测试：
由于还是参数传递，这种依然存在SQL注入问题，要想不存在SQL注入问题，就需要控制用户的入参，可以通过枚举的方式，只能为desc/asc
除了这个之外，还有表名作为参数时,也只能使⽤ ${}
🏀like查询
同样，like使⽤#{}报错
把#{}改成 {}可以正确查出来,但是 {}存在SQL注⼊的问题,所以不能直接使⽤${}
🍀#{}和${}区别总结
- #{}：预编译处理,${}：字符直接替换
- #{}可以防⽌SQL注⼊,${}存在SQL注⼊的⻛险,查询语句中,可以使⽤#{},推荐使⽤#{}
- 但是⼀些场景,#{}不能完成,⽐如排序功能,表名,字段名作为参数时,这些情况需要使⽤${}
- 模糊查询虽然${}可以完成,但因为存在SQL注⼊的问题,所以通常使⽤mysql内置函数concat来完成