首先#{} 和 ${} 都是參數占位符，其中#{}是預編譯處理，${}是字符直接進行替換。預編譯處理是指：MyBatis 在處理#{}時，會將 SQL 中的 #{} 替換為?號，使? PreparedStatement 的 set ?法來賦值。直接替換是指MyBatis 在處理 ${} 時，就是把 ${} 替換成變量的值。

其中#{}與JDBC中的PreparedStatement的作用類似，都可以防止sql注入問題。

但是在單表查詢中，他們都可能會帶來越權查詢和操作數據等問題。下面詳細列出實例：

使用#{}得到JDBC的代碼如下:【針對int類型的參數】

使用${}得到JDBC的代碼如下:【針對int類型的參數】?

?使用${}得到JDBC的代碼如下:【針對String類型的參數】

不難看出這個時候sql語法報錯了。

使用#{}得到JDBC的代碼如下:【針對String類型的參數】

到這里我們就已經可以看出來一些區別了：

1.定義不同:?#{}是預處理;而${}是直接替換。

2.使用不同:?#{}適用于所有類型的參數匹配;但${}只適用數值類型。

3.安全性不同:?#{}性能高，因為他使用占位符已經預編譯了，并且沒有安全問題;?但${}存在SQL注入的安全問題（下面會給出示例）。

那再談談#{}和${}的各自使用場景：

1.${}的使用場景：（對數據進行排序的時候）

但是如果此時使用#{}就會報sql語法錯誤，因為此時需要傳遞的是SQL關鍵字。?

到這里咱們又可以對#{}和${}做一個小結：

當傳遞的是一個SQI.關鍵字（SQI命令）的時候，只能使用${}，此時如果使用#{}就會認為傳遞的為一個普通的值，而非SQL命令，他在替換的時候會自動加上’’號，所以執行就會報錯。

接下來咱們繼續說說剛才在上面總結的那樣，${}存在SQL注入的安全問題。

咱們在實現用戶登錄功能這個場景下，通常需要獲取用戶名和密碼來校驗是否正確，那么這個時候就會出現問題，我們先來正常的查詢：

再繼續看SQL注入的有安全問題：?

?

在sql語法中，1=’1’是正確的，所以這條sql語句也是可以執行的。所以當不得不使用$時，那么一定要在業務代碼中，對傳遞的值進行安全效驗。?

最后再看看like查詢這種場景。

使用#{}:

但是使用${}就可以了：?

但是使用${}還是有安全風險，因為模擬查詢的時候，不知道用戶傳來的是什么數據，我們也不能一一窮舉出來去規避，那么此時使用#{}的時候還有一種方法可以避免安全問題：

?

?

?