目录
MyBatis传参占位符区别
不能直接用#{}的情况
in多参数值查询
like %%模糊查询
order by列名参数化
MyBatis传参占位符区别
在 MyBatis 中,#{}
和 ${}
都是用于传参的占位符,但它们之间有很大的区别,主要体现在两个方面:参数值的类型和 SQL 注入问题。
1.参数值的类型:
① #{} 是预编译参数,表示使用 PreparedStatement 时,使用 setXXX() 方法设置参数值,会对传入的参数进行类型处理,确保传递的参数类型正确。一般来说,我们在使用 MyBatis 进行 CRUD 操作时,都应该使用 #{} 来传递参数,这样可以有效地避免 SQL 注入问题。
② ${} 是字符串拼接,表示在 SQL 语句中直接插入传入的参数值,不会对传入的参数类型进行处理。如果传入的参数是字符串类型,那么在 SQL 语句中使用时,需要使用单引号将其括起来,否则会抛出 SQL 语法错误异常。因此,在使用 ${} 时,需要特别注意避免 SQL 注入问题。
简而言之:
如果传入Z3r'4y
# PrepareStatement ? 填充参数 类型化 转义处理 返回一个'Z3r'4y'
$ Statement 拼接参数 返回一个Z3r'4y
2.SQL 注入问题:
① #{} 可以避免 SQL 注入问题,因为它会对传入的参数进行类型处理,并将参数值转义后再放到 SQL 语句中,保证了 SQL 语句的安全性。
② ${} 存在 SQL 注入问题,因为 SQL 语句中插入的是传入的参数值,如果参数值中包含 SQL 语句的关键字或特殊字符,可能会导致 SQL 注入攻击。
举个例子:
SELECT * FROM tbuser where id= #{id}
SELECT * FROM tbuser where userN服务器托管网ame='${username}'
总结一下:原则就是能用#{}就不要用${}
不能直接用#{}的情况
因为一些sql语言的性质,一些情况不能直接用#{}(传参强制被引号包裹导致sql语义错误)
比如下面这种情况:
如果直接SELECT * FROM tbuser where id in (#{ids})并传参ids=1,2,3就会拼接成:
SELECT * FROM tbuser where id in (‘1,2,3’);
从而出现只调出一行的谬误
解决方案如下:
in多参数值查询
SELECT * FROM tbuser where id in (${ids})
SELECT * FROM tbuser where id in
#{ids}
like %%模糊查询
服务器托管网 SELECT * FROM tbuser where userName like '%${username}%'
SELECT * FROM tbuser where userName like concat('%',#{username}, '%')
order by列名参数化
SELECT *FROM tbuser order by ${colName}
基于MyBatis并不能很好解决这种注入漏洞
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
最近国内访问github.com经常打不开,无法访问。 github网站打不开的服务器托管网解决方法 1.打开网站http://tool.chinaz.com/dns/ ,在A类型的查询中输入 github.com,找出最快的IP地址。 2.修改hosts文件…