這是一次代碼優(yōu)化過程中發(fā)現(xiàn)的問題，在功能優(yōu)化后發(fā)現(xiàn)部分?jǐn)?shù)據(jù)查不到出來了，問題就在于一條sql上的#和$。

下圖為兩條sql：

從圖上可以看出 wwlr.LabelId in(${showLabels}) 和 wwlr.LabelId in(#{showLabels})，其中showLabels是傳進來一個字符串類型的參數(shù)，參數(shù)的樣子是這樣的“4,44,514”，問題就出在這個參數(shù)傳進來后#和$處理的方式是不一樣的。

1、#{ }是預(yù)編譯處理，MyBatis在處理#{ }時，它會將sql中的#{ }替換為？，然后調(diào)用PreparedStatement的set方法來賦值，傳入字符串后，會在值兩邊加上單引號，如上面的值 “4,44,514”就會變成“ ‘4,44,514’ ”；

2、${ }是字符串替換， MyBatis在處理${ }時,它會將sql中的${ }替換為變量的值，傳入的數(shù)據(jù)不會加兩邊加上單引號。

注意：使用${ }會導(dǎo)致sql注入，不利于系統(tǒng)的安全性！

SQL注入：就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。

常見的有匿名登錄（在登錄框輸入惡意的字符串）、借助異常獲取數(shù)據(jù)庫信息等 應(yīng)用場合：

1、#{ }：主要用戶獲取DAO中的參數(shù)數(shù)據(jù),在映射文件的SQL語句中出現(xiàn)#{}表達(dá)式,底層會創(chuàng)建預(yù)編譯的SQL；

2、${ }:主要用于獲取配置文件數(shù)據(jù),DAO接口中的參數(shù)信息,當(dāng)$出現(xiàn)在映射文件的SQL語句中時創(chuàng)建的不是預(yù)編譯的SQL,而是字符串的拼接,有可能會導(dǎo)致SQL注入問題.所以一般使用$接收dao參數(shù)時,這些參數(shù)一般是字段名,表名等,例如order by {column}。

注：

${}獲取DAO參數(shù)數(shù)據(jù)時,參數(shù)必須使用@param注解進行修飾或者使用下標(biāo)或者參數(shù)#{param1}形式；

#{}獲取DAO參數(shù)數(shù)據(jù)時,假如參數(shù)個數(shù)多于一個可有選擇的使用@param。

其實剛開始我也沒太去看sql里的#和$，我把sql放到數(shù)據(jù)庫跑一切正常，所以我就將代碼的執(zhí)行sql輸出到控制臺了，具體是這么一個輸出sql的配置文件：

輸出后，終于發(fā)現(xiàn)了問題在哪里。。。。

看了上面的區(qū)別介紹，相信大家其實都應(yīng)該知道區(qū)別在哪里，我們的問題在哪里，其實就是sql在in的時候 ，里面的數(shù)據(jù)被加了兩個雙引號?！皐wlr.LabelId in（4,44,514）就會變成 wwlr.LabelId in（’4,44,514′ ）；所以導(dǎo)致部分?jǐn)?shù)據(jù)查不到了。

解決辦法

1、快速解決

最快的方法就是把#直接替換成$，這樣問題應(yīng)該就可以解決了。

但是，我很無語，我確沒有解決。

本地跑代碼一點問題都沒有，部署到公司的docker上問題一樣沒解決，給人的感覺就是代碼根本沒有從#變$。

大家都知道$其實是有危險性，會容易被sql注入，具我所知道，我們公司的docker是會加一層防止 sql注入的功能 ，所以不知道是不是這個功能把的$無效掉了。

當(dāng)然，我也沒有去再到服務(wù)上打出sql來看一下，因為本來$就是不太安全的，所以我換了一種方式處理。 2、foreach標(biāo)簽的使用

foreach標(biāo)簽主要用于構(gòu)建in條件，他可以在sql中對集合進行迭代。

先來看看語法：

通過上圖，大家也應(yīng)該也了解和使用這個標(biāo)簽了吧。

那對于我們項目中的改造，其實就是把原來傳進來的字符型參數(shù)變成List<Integer>，這樣問題就完美的解決了，既實現(xiàn)了我們的功能 ，又解決了安全性問題。

到此這篇關(guān)于MyBatis中$和#深入講解的文章就介紹到這了,更多相關(guān)MyBatis中$和#內(nèi)容請搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！