SQL 注入是一種程式碼注入技術，用於攻擊資料驅動的應用，惡意的SQL 語句被插入到執行的實體欄位中（例如，為了轉儲資料庫內容給攻擊者）。[摘自]  SQL注入 - 維基百科SQL注入，大家都不陌生，是一種常見的攻擊方式。攻擊者在介面的表單資訊或URL上輸入一些奇怪的SQL片段（例如“或'1'='1'”這樣的語句），有可能入侵引數檢驗不足的應用程式。所以，在我們的應用中需要做一些，來防備這樣的攻擊方式。在一些安全性要求很高的應用（比如銀行軟體），經常使用將 SQL 語句全部替換為儲存過程這樣的方式，來防止SQL注入。當然這的英文一種很安全的方式

MyBatis的框架作為一款半自動化的ORM框架，其SQL語句都要我們自己手動編寫，這個時候當然需要防止SQL 注入。其實，MyBatis的SQL的是一個具有“ 輸入+ 輸出 ”的功能，類似於函式的結構，如下：

<select id =“ getBlogById ”resultType =“ Blog ”parameterType =“ int ”>

         SELECT id，title，author，content

         來自部落格

WHERE id =＃{id}

</選擇>

這裡，引數型別表示了輸入的引數型別，與resultType表示了輸出的引數型別，迴應上文，如果我們想防止SQL注入，理所當然地要在輸入引數上下功夫。上面程式碼中黃色高亮即輸入引數在SQL中拼接的部分，傳入引數後，打印出執行的SQL語句，會看到SQL是這樣的：

SELECT id，title，author，content FROM blog WHERE id =？

。不管輸入什麼引數，打印出的SQL都是這樣的這是因為MyBatis的啟用了預編譯功能，在SQL執行前，會先將上面的SQL傳送給資料庫進行編譯;執行時，直接使用編譯好的SQL ，替換佔位符“？”就可以了。因為SQL注入只能對編譯過程起作用，所以這樣的方式就很好地避免了SQL注入的問題。

【底層實現原理】

      其原因就是：採用了JDBC的PreparedStatement，就會將sql語句：“select id，no from user where id =？” 預先編譯好，也就是SQL引擎會預先進行語法分析，產生語法樹，生成執行計劃，也就是說，後面你輸入的引數，無論你輸入的是什麼，都不會影響該SQL語句的語法結構了，因為語法分析已經完成了，而語法分析主要是分析sql命令，比如select，from，where，and，or，order by等等。所以即使你後面輸入了這些sql命令，也不會被當成sql命令來執行了，因為這些SQL命令的執行，必須先得通過語法分析，生成執行計劃，既然語法分析已經完成，已經預編譯過了，那麼後面輸入的引數，是絕對不可能作為SQL命令來執行的，只會被當做字串字面值引數。所以的sql語句預編譯可以防禦SQL注入。而且在多次執行同一個SQL時，能夠提高效率。原因是SQL已編譯好，再次執行時無需再編譯。

話說回來，是否我們使用的MyBatis就一定可以防止SQL注入呢當然不是，請看下面的程式碼？

<select id =“ getBlogById ”resultType =“ Blog ”parameterType =“ int ”>

         SELECT id，title，author，content

         來自部落格

WHERE id = $ {id}

</選擇>

仔細觀察，內聯引數的格式由“ ＃ {xxx}”變為了“ $ {xxx}”。如果我們給引數“ id ”賦值為“ 3 ”，將SQL打印出來是這樣的：

SELECT id，title，author，content FROM blog WHERE id = 3

（上面的對比示例是我自己新增的，為了與前面的示例形成鮮明的對比。）

<select id =“ orderBlog ”resultType =“ Blog ”parameterType =“ map ”>

         SELECT id，title，author，content

         來自部落格

ORDER BY $ {orderParam}

</選擇>

仔細觀察，內聯引數的格式由“ ＃ {xxx}”變為了“ $ {xxx}”。如果我們給引數“ orderParam ”賦值為“ id ”，將SQL打印出來是這樣的：

SELECT id，title，author，content FROM blog ORDER BY id

顯然，這樣是無法阻止SQL 注入的。在MyBatis中，“ $ {xxx}”這樣格式的引數會直接參與SQL 編譯，從而不能避免注入攻擊。但涉及到動態表名和列名時，只能使用$ {xxx}“這樣的引數格式。所以，這樣的引數需要我們在程式碼中手工進行處理來防止注入。

【結論】在編寫MyBatis的對映語句時，儘量採用“ ＃ {xxx}”這樣的格式。若不得不使用“ $ {xxx}”這樣的引數，要手工地做好過濾工作，來防止SQL注入攻擊。

＃{}：相當於JDBC中的PreparedStatement的

$ {}：是輸出變數的值

簡單說，＃ {}是經過預編譯的，是安全的 ; $ {}是未經過預編譯的，僅僅是取變數的值，是非安全的，存在SQL注入。

如果我們通過語句後用了訂單$ {}，那麼不做任何處理的時候是存在SQL注入危險的。你說怎麼防止，那我只能悲慘的告訴你，你得手動處理過濾一下輸入的內容。如判斷一下輸入的引數的長度是否正常（注入語句一般很長），更精確的過濾則可以查詢一下輸入側的引數是否在預期的引數集合中。