Mybatis中單雙引號引發(fā)的慘案及解決

更新時間：2022年01月14日 09:41:10 作者：爆米花機槍手

這篇文章主要介紹了Mybatis中單雙引號引發(fā)的慘案及解決方式，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教

#{}與${}的區(qū)別

#{}是預編譯處理，${}是字符串替換Mybatis在處理#{}時，會將sql中的#{}替換為?號，調(diào)用PreparedStatement的set方法來賦值；

Mybatis在處理時，就是把 {}時，就是把時，就是把{}替換成變量的值。

使用#{}可以有效的防止SQL注入，提高系統(tǒng)安全性。

再通俗的說，使用${}mybatis會把參數(shù)加上雙引號，而${} 你給啥，sql語句中就是啥，如下示例:

select * from table where name = #{name} ?name->小明?
## 結果：select * from table where name = "小明"
select * from table where name = ${name} ?name->小明?
## 結果：select * from table where name = 小明

問題

最近有個功能需要從sqlserver中去數(shù)據(jù)，有個腳本很簡單如下:

select * from table where id in(...)?

id已經(jīng)創(chuàng)建索引了，考慮到數(shù)據(jù)傳輸，我每次設置的集合大小為100個，因為這是再簡單不過的語句了，直接上線給別人使用，但是別人的反饋是，使用50個id需要40多秒?。?！這就有點嚇人了，幸好此場景只是在半夜定時的去使用，慢一點不會對第二天有影響，但是白天想要測試的時候就懵了。當然了40多s就別提是否影響別人使用了，基本上就已經(jīng)崩潰了好不好?。。?/p>

這就有點嚇人了，幸好此場景只是在半夜定時的去使用，慢一點不會對第二天有影響，但是白天想要測試的時候就懵了。當然了40多s就別提是否影響別人使用了，基本上就已經(jī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í)行報錯了，后面把雙引號改成單引號就行了，即

SELECT id ,tid FROM table where id IN ( '123','234','345'...);
耗時: 0.092s

記住這里的單雙引號的問題

??? 很快啊，這是什么情況，第一次遇到這種情況，直接運行sql很快，但是通過mybatis就很慢。

所以我首先懷疑是ORM框架的問題，接著我用JDBC快速寫了個demo，來驗證，代碼如下：

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"));
}
// 耗時0.109ms

這里也是很快，沒什么問題，忽略ORM的問題。

因為我這里用的是Mybatis-Plus，所以我又懷疑是mp的問題，于是debug代碼，最后卡在這個地方:

//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也被排除！

這個時候已經(jīng)過去很長時間了，整個人很懵，怎么會這樣？？？這么簡單的sql還會出這么大的問題！我重新理了下思緒，此處的sql是在sqlserver上執(zhí)行的，那會不會是sqlserver上的問題呢？

我突然靈光一閃，剛剛debug出來的腳本直接放在sqlserver的客戶端上執(zhí)行的時候是有問題的，我后面是把雙引號改成單引號才成功的，我趕緊調(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: ....

耗時: 0.100s!!!

如釋重負，原來是雙引號惹的禍！

SqlServer是不支持雙引號的，但是mybatis最后生成的sql使用的雙引號，當然這對mysql是沒問題的，當然也有例外

如果SQL服務器模式啟用了NSI_QUOTES，可以只用單引號引用字符串。用雙引號引用的字符串被解釋為一個識別符。

所以我遇到的情況是就是生成帶雙引號的腳本丟給sqlserver執(zhí)行的時候，被sql服務器誤認為是一個識別符，類似java中類型的強轉，此時索引是不生效的，也就是說一開的in查詢時沒有使用到索引的?。?！話說那個表中有700w條記錄，怪不得每次查詢50條的時候，耗時很均勻，都在40多秒。。。。。

回到開頭，這種情況就是借助${}來解決，當然是用它是有隱患的，因為它并不能防止sql注入，但是對于我這邊的場景不會出現(xiàn)這種情況，所以我趕緊的把其他地方也都改了過來！??！

最后

解決問題還是要大膽假設，小心求證事實的真相只有一個?。?！

另外在debug的時候，順便看到了#{}和${}的拼接代碼，放在了下面

// 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();
}

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

您可能感興趣的文章:

struts2.2.3+spring3.1.0+mybatis3.1.0框架整合集成簡單demo
本篇文章主要介紹了struts2.2.3+spring3.1.0 + mybatis3.1.0框架整合，結合在一起實現(xiàn)用戶的增刪改查功能，有需要的可以了解一下。
2016-11-11
詳解Java的readBytes是怎么實現(xiàn)的
眾所周知，Java是一門跨平臺語言，針對不同的操作系統(tǒng)有不同的實現(xiàn)，下面小編就來從一個非常簡單的api調(diào)用帶大家來看看Java具體是怎么做的吧
2023-07-07
詳解maven配置多倉庫的方法示例
這篇文章主要介紹了詳解maven配置多倉庫的方法示例，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧
2020-08-08
JAVA中對List進行查詢
下面小編就為大家?guī)硪黄趈ava List中進行模糊查詢的實現(xiàn)方法。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧
2021-08-08
mybatis攔截器實現(xiàn)通用權限字段添加的方法
這篇文章主要給大家介紹了關于mybatis攔截器實現(xiàn)通用權限字段添加的相關資料，文中通過示例代碼介紹的非常詳細，對大家學習或者使用mybatis具有一定的參考學習價值，需要的朋友們下面來一起學習學習吧
2019-09-09
java項目實現(xiàn)猜拳小游戲
這篇文章主要為大家詳細介紹了java項目實現(xiàn)猜拳小游戲，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下
2020-05-05
SpringMVC實現(xiàn)參數(shù)校驗配置方法
這篇文章主要介紹了SpringMVC實現(xiàn)參數(shù)校驗的配置方式，Spring MVC會拋出MethodArgumentNotValidException異常，并將錯誤信息綁定到相應的字段上,感興趣的朋友跟隨小編一起看看吧
2024-03-03
關于Java類的構造方法詳解
這篇文章主要介紹了關于Java類的構造方法詳解的相關資料,需要的朋友可以參考下
2023-01-01
解決IDEA插件市場Plugins無法加載的問題
這篇文章主要介紹了解決IDEA插件市場Plugins無法加載的問題,本文通過圖文并茂的形式給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下
2020-10-10
Java實現(xiàn)Web應用中的定時任務(實例講解)
下面小編就為大家分享一篇Java實現(xiàn)Web 應用中的定時任務的實例講解，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧
2017-11-11