Mybatis中單雙引號引發(fā)的慘案及解決
#{}與${}的區(qū)別
#{}是預(yù)編譯處理,${}是字符串替換Mybatis在處理#{}時(shí),會(huì)將sql中的#{}替換為?號, 調(diào)用PreparedStatement的set方法來賦值;
Mybatis在處理時(shí) , 就 是 把 {}時(shí),就是把時(shí),就是把{}替換成變量的值。
使用#{}可以有效的防止SQL注入,提高系統(tǒng)安全性。
再通俗的說,使用${}mybatis會(huì)把參數(shù)加上雙引號,而${} 你給啥,sql語句中就是啥,如下示例:
select * from table where name = #{name} ?name->小明?
## 結(jié)果:select * from table where name = "小明"
select * from table where name = ${name} ?name->小明?
## 結(jié)果:select * from table where name = 小明問題
最近有個(gè)功能需要從sqlserver中去數(shù)據(jù),有個(gè)腳本很簡單如下:
select * from table where id in(...)?
id已經(jīng)創(chuàng)建索引了,考慮到數(shù)據(jù)傳輸,我每次設(shè)置的集合大小為100個(gè),因?yàn)檫@是再簡單不過的語句了,直接上線給別人使用,但是別人的反饋是,使用50個(gè)id需要40多秒?。。?這就有點(diǎn)嚇人了,幸好此場景只是在半夜定時(shí)的去使用,慢一點(diǎn)不會(huì)對第二天有影響,但是白天想要測試的時(shí)候就懵了。當(dāng)然了40多s就別提是否影響別人使用了,基本上就已經(jīng)崩潰了好不好?。。?/p>
這就有點(diǎn)嚇人了,幸好此場景只是在半夜定時(shí)的去使用,慢一點(diǎn)不會(huì)對第二天有影響,但是白天想要測試的時(shí)候就懵了。當(dāng)然了40多s就別提是否影響別人使用了,基本上就已經(jīng)崩潰了好不好?。。?/p>
下面簡化了一下,對應(yīng)的xml代碼如下:
<select id="selectTbdIdByLbdIdList" resultType="xxx.xxx.xxMapper">
? ? SELECT id ,tid FROM table where id IN
? ? <foreach collection="list" item="item" open="(" close=")" separator=",">
? ? ? ? #{item}
? ? </foreach>
</select>debug 模式下的輸出如下:
| ==> Preparing: SELECT id ,tid FROM table where id IN ( ?,?,?,?,?,?...)
| ==> Parameters: 123(String),234(String),345(String),456(String),
| <== Total: ....
我把sql整理出來放在sqlserver客戶端去執(zhí)行
SELECT id ,tid FROM table where id IN ( "123","234","345"...);
剛開始執(zhí)行報(bào)錯(cuò)了,后面把雙引號改成單引號就行了,即
SELECT id ,tid FROM table where id IN ( '123','234','345'...); 耗時(shí): 0.092s
記住這里的單雙引號的問題
??? 很快啊,這是什么情況,第一次遇到這種情況,直接運(yùn)行sql很快,但是通過mybatis就很慢。
所以我首先懷疑是ORM框架的問題,接著我用JDBC快速寫了個(gè)demo,來驗(yàn)證,代碼如下:
String connectionUrl = "jdbc:sqlserver://xxx:8838;DatabaseName=xxx;user=xxx;password=xx";
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
Connection con = DriverManager.getConnection(connectionUrl);
Statement stmt = con.createStatement();
String SQL = "SELECT id ,tid FROM table where id IN ( '123','234','345'...)";
long s = System.nanoTime();
ResultSet rs = stmt.executeQuery(SQL);
System.out.println((System.nanoTime() - s) / 1_000_000);
// Iterate through the data in the result set and display it.
while (rs.next()) {
? ? System.out.println(rs.getString("id") + " ---> " + rs.getString("tid"));
}
// 耗時(shí)0.109ms這里也是很快,沒什么問題,忽略O(shè)RM的問題。
因?yàn)槲疫@里用的是Mybatis-Plus,所以我又懷疑是mp的問題,于是debug代碼,最后卡在這個(gè)地方:
//PreparedStatementHandler.class
public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
? ? PreparedStatement ps = (PreparedStatement) statement;
? ? ps.execute();// 卡在這一行
? ? return resultSetHandler.handleResultSets(ps);
}但這是Mybatis的代碼,再者說mp只是簡化了代碼生成這一塊,對Mybatis本身的執(zhí)行沒有影響,所以mp也被排除!
這個(gè)時(shí)候已經(jīng)過去很長時(shí)間了,整個(gè)人很懵,怎么會(huì)這樣???這么簡單的sql還會(huì)出這么大的問題!我重新理了下思緒,此處的sql是在sqlserver上執(zhí)行的,那會(huì)不會(huì)是sqlserver上的問題呢?
我突然靈光一閃,剛剛debug出來的腳本直接放在sqlserver的客戶端上執(zhí)行的時(shí)候是有問題的,我后面是把雙引號改成單引號才成功的,我趕緊調(diào)整了xml中的腳本,如下:
<select id="selectTbdIdByLbdIdList" resultType="xxx.xxx.xxMapper">
? ? SELECT id ,tid FROM table where id IN
? ? <foreach collection="list" item="item" open="(" close=")" separator=",">
? ? ? ? '${item}'
? ? </foreach>
</select>然后再執(zhí)行,debug出來的腳本如下:
| ==> Preparing: SELECT id ,tid FROM table where id IN ( '123','234','345','456'...)
| ==> Parameters:
| <== Total: ....
耗時(shí): 0.100s!!!
如釋重負(fù),原來是雙引號惹的禍!
SqlServer是不支持雙引號的,但是mybatis最后生成的sql使用的雙引號,當(dāng)然這對mysql是沒問題的,當(dāng)然也有例外
如果SQL服務(wù)器模式啟用了NSI_QUOTES,可以只用單引號引用字符串。用雙引號引用的字符串被解釋為一個(gè)識別符。
所以我遇到的情況是就是生成帶雙引號的腳本丟給sqlserver執(zhí)行的時(shí)候,被sql服務(wù)器誤認(rèn)為是一個(gè)識別符,類似java中類型的強(qiáng)轉(zhuǎn),此時(shí)索引是不生效的,也就是說一開的in查詢時(shí)沒有使用到索引的?。。≡捳f那個(gè)表中有700w條記錄,怪不得每次查詢50條的時(shí)候,耗時(shí)很均勻,都在40多秒。。。。。
回到開頭,這種情況就是借助${}來解決,當(dāng)然是用它是有隱患的,因?yàn)樗⒉荒芊乐箂ql注入,但是對于我這邊的場景不會(huì)出現(xiàn)這種情況,所以我趕緊的把其他地方也都改了過來?。?!
最后
解決問題還是要大膽假設(shè),小心求證 事實(shí)的真相只有一個(gè)?。。?/p>
另外在debug的時(shí)候,順便看到了#{}和${}的拼接代碼,放在了下面
// ForEachSqlNode
public void appendSql(String sql) {
GenericTokenParser parser = new GenericTokenParser("#{", "}", content -> {
String newContent = content.replaceFirst("^\\s*" + item + "(?![^.,:\\s])", itemizeItem(item, index));
if (itemIndex != null && newContent.equals(content)) {
newContent = content.replaceFirst("^\\s*" + itemIndex + "(?![^.,:\\s])", itemizeItem(itemIndex, index));
}
return "#{" + newContent + "}";
});
delegate.appendSql(parser.parse(sql));
}
// TextSqlNode
private GenericTokenParser createParser(TokenHandler handler) {
return new GenericTokenParser("${", "}", handler);
}
// GenericTokenParser
public String parse(String text) {
if (text == null || text.isEmpty()) {
return "";
}
// search open token
int start = text.indexOf(openToken);
if (start == -1) {
return text;
}
char[] src = text.toCharArray();
int offset = 0;
final StringBuilder builder = new StringBuilder();
StringBuilder expression = null;
while (start > -1) {
if (start > 0 && src[start - 1] == '\\') {
// this open token is escaped. remove the backslash and continue.
builder.append(src, offset, start - offset - 1).append(openToken);
offset = start + openToken.length();
} else {
// found open token. let's search close token.
if (expression == null) {
expression = new StringBuilder();
} else {
expression.setLength(0);
}
builder.append(src, offset, start - offset);
offset = start + openToken.length();
int end = text.indexOf(closeToken, offset);
while (end > -1) {
if (end > offset && src[end - 1] == '\\') {
// this close token is escaped. remove the backslash and continue.
expression.append(src, offset, end - offset - 1).append(closeToken);
offset = end + closeToken.length();
end = text.indexOf(closeToken, offset);
} else {
expression.append(src, offset, end - offset);
offset = end + closeToken.length();
break;
}
}
if (end == -1) {
// close token was not found.
builder.append(src, start, src.length - start);
offset = src.length;
} else {
builder.append(handler.handleToken(expression.toString()));
offset = end + closeToken.length();
}
}
start = text.indexOf(openToken, offset);
}
if (offset < src.length) {
builder.append(src, offset, src.length - offset);
}
return builder.toString();
}
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
struts2.2.3+spring3.1.0+mybatis3.1.0框架整合集成簡單demo
本篇文章主要介紹了struts2.2.3+spring3.1.0 + mybatis3.1.0框架整合,結(jié)合在一起實(shí)現(xiàn)用戶的增刪改查功能,有需要的可以了解一下。2016-11-11
詳解Java的readBytes是怎么實(shí)現(xiàn)的
眾所周知,Java是一門跨平臺語言,針對不同的操作系統(tǒng)有不同的實(shí)現(xiàn),下面小編就來從一個(gè)非常簡單的api調(diào)用帶大家來看看Java具體是怎么做的吧2023-07-07
mybatis攔截器實(shí)現(xiàn)通用權(quán)限字段添加的方法
這篇文章主要給大家介紹了關(guān)于mybatis攔截器實(shí)現(xiàn)通用權(quán)限字段添加的相關(guān)資料,文中通過示例代碼介紹的非常詳細(xì),對大家學(xué)習(xí)或者使用mybatis具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧2019-09-09
java項(xiàng)目實(shí)現(xiàn)猜拳小游戲
這篇文章主要為大家詳細(xì)介紹了java項(xiàng)目實(shí)現(xiàn)猜拳小游戲,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2020-05-05
SpringMVC實(shí)現(xiàn)參數(shù)校驗(yàn)配置方法
這篇文章主要介紹了SpringMVC實(shí)現(xiàn)參數(shù)校驗(yàn)的配置方式,Spring MVC會(huì)拋出MethodArgumentNotValidException異常,并將錯(cuò)誤信息綁定到相應(yīng)的字段上,感興趣的朋友跟隨小編一起看看吧2024-03-03
Java實(shí)現(xiàn)Web應(yīng)用中的定時(shí)任務(wù)(實(shí)例講解)
下面小編就為大家分享一篇Java實(shí)現(xiàn)Web 應(yīng)用中的定時(shí)任務(wù)的實(shí)例講解,具有很好的參考價(jià)值,希望對大家有所幫助。一起跟隨小編過來看看吧2017-11-11

