最近讀了程序員的SQL金典這本書，覺得里面的SQL注入漏洞和SQL調優總結得不錯，下面簡單討論下SQL注入漏洞和SQL調優。
1. SQL注入漏洞
由於“'1'='1'”這個表達式永遠返回 true，而 true 與任何布爾值的 or 運算的結果都是 true，那么無論正確密碼是什么“Password='1' or '1'='1'”的計算值永遠是 true，這樣惡意攻擊者就可以使用任何帳戶登錄系統了。這樣的漏洞就被稱作“SQL 注入漏洞（SQL Injection）”。
對付 SQL 注入漏洞有兩種方式：過濾敏感字符和使用參數化 SQL。
1).過濾敏感字符
過濾敏感字符的思路非常簡單，由於惡意攻擊者一般需要在輸入框中輸入的文本一般含有 or、and、select、delete 之類的字符串片段，所以在拼接 SQL 之前檢查用戶提交的文本中是否含有這些敏感字符串，如果含有則終止操作。
2).使用參數化SQL
為運行時才能確定的用戶名和密碼設置了占位符，然后在運行時再設定占位符的值，在執行時 Java、C#會直接將參數化 SQL 以及對應的參數值傳遞給 DBMS，在 DBMS 中會將參數值當成一個普通的值來處理而不是將它們拼接到參數化 SQL 中，因此從根本上避免了 SQL 注入漏洞攻擊。
2. SQL 調優
在使用 DBMS 時經常對系統的性能有非常高的要求：不能占用過多的系統內存和CPU 資源、要盡可能快的完成的數據庫操作、要有盡可能高的系統吞吐量。如果系統開發出來不能滿足要求的所有性能指標，則必須對系統進行調整，這個工作被稱為調優。
SQL 調優的基本原則
“二八原理”是一個普遍的真理，特別是在計算機的世界中表現的更加明顯，那就是 20%的代碼的資源消耗占用了 80%的總資源消耗。SQL 語句也是一種代碼，因此它也符合這個原理。在進行 SQL 調優的時候應該把主要精力放到這 20%的最消耗系統資源的 SQL 語句中，不要想把所有的 SQL 語句都調整到最優狀態。
索引是數據庫調優的最根本的優化方法。
常用的SQL調優方法：
1) 創建必要的索引
2) 使用預編譯查詢
程序中通常是根據用戶的輸入來動態執行 SQL 語句，這時應該盡量使用參數化SQL，這樣不僅可以避免 SQL 注入漏洞攻擊，最重要數據庫會對這些參數化 SQL 執行預編譯。
3) 調整 WHERE 子句中的連接順序
DBMS 一般采用自下而上的順序解析 WHERE 子句，根據這個原理,表連接最好寫在其他 WHERE 條件之前，那些可以過濾掉最大數量記錄。
比如下面的 SQL 語句性能較差： SELECT * FROM T_Person WHERE FSalary > 50000 AND FPosition= ‘MANAGER’ AND 25 < (SELECT COUNT(*) FROM T_Manager WHERE FManagerId=2);
我們將子查詢的條件放到最前面，下面的 SQL 語句性能比較好： SELECT * FROM T_Person WHERE 25 < (SELECT COUNT(*) FROM T_Manager WHERE FManagerId=2) AND FSalary > 50000 AND FPosition= ‘MANAGER’ ;
4) SELECT 語句中避免使用'*'
SELECT *比較簡單，但是除非確實需要檢索所有的列，否則將會檢索出不需要的列，這回增加網絡的負載和服務器的資源消耗；即使確實需要檢索所有列，也不要使用SELECT *，因為這是一個非常低效的方法，DBMS 在解析的過程中，會將*依次轉換成所有的列名，這意味着將耗費更多的時間。
5) 盡量將多條 SQL 語句壓縮到一句 SQL 中
每次執行 SQL 的時候都要建立網絡連接、進行權限校驗、進行 SQL 語句的查詢優化、發送執行結果，這個過程是非常耗時的，因此應該盡量避免過多的執行 SQL 語句，能夠壓縮到一句 SQL 執行的語句就不要用多條來執行。
6) 用 Where 子句替換 HAVING 子句
避免使用 HAVING 子句，因為 HAVING 只會在檢索出所有記錄之后才對結果集進行過濾。如果能通過 WHERE 子句限制記錄的數目，那就能減少這方面的開銷。HAVING 中的條件一般用於聚合函數的過濾，除此而外，應該將條件寫在 WHERE 子句中。
7) 使用表的別名
當在 SQL 語句中連接多個表時，請使用表的別名並把別名前綴於每個列名上。這樣就可以減少解析的時間並減少那些由列名歧義引起的語法錯誤。
8) 用 EXISTS 替代 IN
在查詢中，為了滿足一個條件，往往需要對另一個表進行聯接，在這種情況下，使用 EXISTS 而不是 IN 通常將提高查詢的效率，因為 IN 子句將執行一個子查詢內部的排序和合並。
9) 用表連接替換 EXISTS
通常來說，表連接的方式比 EXISTS 更有效率，因此如果可能的話盡量使用表連接替換 EXISTS。
10) 避免在索引列上使用計算
在 WHERE 子句中，如果索引列是計算或者函數的一部分，DBMS 的優化器將不會使用索引而使用全表掃描。
11) 用 UNION ALL 替換 UNION
當 SQL 語句需要 UNION 兩個查詢結果集合時，即使檢索結果中不會有重復的記錄，如果使用 UNION 這兩個結果集同樣會嘗試進行合並，然后在輸出最終結果前進行排序。 因此，如果檢索結果中不會有重復的記錄的話，應該用 UNION ALL 替代 UNION，這樣效率就會因此得到提高。
12) 避免隱式類型轉換造成的全表掃描
13) 防止檢索范圍過寬
如果 DBMS 優化器認為檢索范圍過寬，那么它將放棄索引查找而使用全表掃描。下面是幾種可能造成檢索范圍過寬的情況： 使用 IS NOT NULL 或者不等於判斷，可能造成優化器假設匹配的記錄數太多。 使用 LIKE 運算符的時候，"a%"將會使用索引，而"a%c"和"%c"則會使用全表掃描，因此"a%c"和"%c"不能被有效的評估匹配的數量。
如果您有什么問題，歡迎在下面評論，我們一起討論，謝謝~
如果您覺得還不錯，不妨點下右下方的推薦，有您的鼓勵我會繼續努力的~