【JavaEE】MyBatis 单表查询易错问题（添加后返回自增id，${}与#{}，SQL注入，模糊查询）

1. 添加用户，返回受影响的行数

UserMapper 接口声明：

mapper.xml实现如下：

单元测试如下：

结果如下：

2. 添加用户，返回自增的id

mapper接口声明：

mapper.xml实现：

单元测试代码：

结果：

相关注解：

• useGeneratedKeys：令 MyBatis 使⽤ JDBC 的 getGeneratedKeys ⽅法来取出由数据库内部⽣成的主键（⽐如：像 MySQL 和 SQL Server 这样的关系型数据库管理系统的⾃动递增字段），默认值：false。需要手动设置 TRUE
• keyColumn：设置⽣成键值在表中的列名，在某些数据库（像 PostgreSQL）中，当主键列不是表中的第⼀列的时候，是必须设置的。如果⽣成列不⽌⼀个，可以⽤逗号分隔多个属性名称。（映射数据表中的字段）
• keyProperty：指定能够唯⼀识别对象的属性，MyBatis 会使⽤ getGeneratedKeys 的返回值或 insert 语句的 selectKey ⼦元素设置它的值，默认值：未设置（unset）。如果⽣成列不⽌⼀个，可以⽤逗号分隔多个属性名称。（映射对应数据表的类的属性）

3. 参数占位符 #{} 和 ${}

• #{}：预编译处理。
• ${}：字符直接替换。
• 预编译处理是指：MyBatis 在处理#{}时，会将 SQL 中的 #{} 替换为?号，使⽤ PreparedStatement 的set ⽅法来赋值。（列如在进行字符串复制时会自动加上 ‘’）
• 直接替换：是MyBatis 在处理 ${} 时，就是把 ${} 替换成变量的值。

3.1 ${} 优点

在进行需要对查询的结果排序（order）时候就需要使用${}，如果使用#{}在进行SQL拼接时候会给排序规则（asc,desc）加上 ’ ’ 导致SQL语句报错

mapper接口：

mapper.xml实现：

单元测试：


直接替换才能查询成功，使用#{}反而会报错：

3.2 #{} VS ${} 区别：

1. 定义不同 : #{} 是预处理，${} 是直接替换
2. 使用不同：#{} 适用于所有类型的参数匹配，${} 只适用于数值类型
3. 安全性不同： #{}性能高，并且没有安全问题；但 ${} 存在SQL注入的安全问题

4. SQL 注入问题

假设实现一个登录功能，此时数据库中只有admin一条用户信息（账号密码均为admin）：

mapper接口：

xml实现：（使用直接替换的${}）：

在正常输入正确的账号密码时候能够实现登录（查询到完整的用户信息）：
单元测试代码：


sql 注⼊代码：“’ or 1='1”

发现即使在用户没有正确输入密码的情况下也能成功查询到完整的用户信息：

这就是SQL注入问题；

结论：用于查询的字段，尽量使用 #{} 预查询的方式。

5. like 查询

在进行like模糊查询时 使⽤ #{} 报错：

mapper接口：

xml实现：

单元测试：

报错：

原因如下：相当于： select * from userinfo where username like ‘%‘username’%’; 又加了一次 ’ ’ 所以肯定是查询不出来的：

这个是不能直接使⽤ ${}，可以考虑使⽤ mysql 的内置函数 concat() 来处理，实现代码如下：


单元测试：

模糊查询成功~

• 本篇完 ，over ~