什么是SQL注入？？
所謂SQL注入，就是通過把SQL命令插入到Web表單提交或頁面請求url的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將（惡意）的SQL命令注入到后台數據庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。
實戰舉例
有個登陸框如下：
可以看到除了賬號密碼之外，還有一個公司名的輸入框，根據輸入框的形式不難推出SQL的寫法如下：
SELECT * From table_name WHERE name=‘XX’ and password=‘YY’ and corporate=‘ZZ’
怎么做呢，？
因為沒有校驗，因此，我們賬號密碼，都不填寫，直接在最后，添加 or 1=1 –
看看與上面SQL組合，成了如下：
SELECT * From table_name WHERE name=’’ and password=’’ and corporate=’’ or 1=1-’
從代碼可以看出，前一半單引號被閉合，后一半單引號被 “–”給注釋掉，中間多了一個永遠成立的條件“1=1”，這就造成任何字符都能成功登錄的結果。
重要提醒
不要以為在輸入框做個檢查就夠了，不要忘記了，我們web提交表單，是可以模擬url直接訪問過去，繞開前段檢查。因此，必須是后端，或是數據來檢查才能有效防止。
（1）檢查用戶輸入的合法性；
（2）將用戶的登錄名、密碼等數據加密保存。
（3）預處理SQL。
（4）使用存儲過程實現查詢，雖然不推薦，但也是一個方法。
MySQL預處理是怎么防止的呢？
MyBatis框架作為一款半自動化的持久層框架，其SQL語句都要我們自己手動編寫，這個時候當然需要防止SQL注入。其實，MyBatis的SQL是一個具有“輸入+輸出”的功能，類似於函數的結構，如下：
<select id="getBlogById" resultType="Blog" parameterType=”int”>
SELECT id,title,author,content
FROM blog
WHERE id=#{id}
</select>
這里，parameterType表示了輸入的參數類型，resultType表示了輸出的參數類型。回應上文，如果我們想防止SQL注入，理所當然地要在輸入參數上下功夫。上面代碼中黃色高亮即輸入參數在SQL中拼接的部分，傳入參數后，打印出執行的SQL語句，會看到SQL是這樣的：
SELECT id,title,author,content FROM blog WHERE id = ?
不管輸入什么參數，打印出的SQL都是這樣的。這是因為MyBatis啟用了預編譯功能，在SQL執行前，會先將上面的SQL發送給數據庫進行編譯；執行時，直接使用編譯好的SQL，替換占位符“?”就可以了。因為SQL注入只能對編譯過程起作用，所以這樣的方式就很好地避免了SQL注入的問題。
【底層實現原理】MyBatis是如何做到SQL預編譯的呢？其實在框架底層，是JDBC中的PreparedStatement類在起作用，PreparedStatement是我們很熟悉的Statement的子類，它的對象包含了編譯好的SQL語句。這種“准備好”的方式不僅能提高安全性，而且在多次執行同一個SQL時，能夠提高效率。原因是SQL已編譯好，再次執行時無需再編譯。
話說回來，是否我們使用MyBatis就一定可以防止SQL注入呢？當然不是，請看下面的代碼：
<select id="getBlogById" resultType="Blog" parameterType=”int”>
SELECT id,title,author,content
FROM blog
WHERE id=${id}
</select>
仔細觀察，內聯參數的格式由“#{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
FROM blog
ORDER BY ${orderParam}
</select>
仔細觀察，內聯參數的格式由“#{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注入。
如果我們order by語句后用了${}，那么不做任何處理的時候是存在SQL注入危險的。你說怎么防止，那我只能悲慘的告訴你，你得手動處理過濾一下輸入的內容。如判斷一下輸入的參數的長度是否正常（注入語句一般很長），更精確的過濾則可以查詢一下輸入的參數是否在預期的參數集合中。