原文: 讀書(shū)筆記之SQL注入漏洞和SQL調(diào)優(yōu)

　　最近讀了 程序員的SQL金典 這本書(shū)，覺(jué)得里面的SQL注入漏洞和SQL調(diào)優(yōu)總結(jié)得不錯(cuò)，下面簡(jiǎn)單討論下SQL注入漏洞和SQL調(diào)優(yōu)。

1.?SQL 注入漏洞

　　由于“ '1'='1' ”這個(gè)表達(dá)式永遠(yuǎn)返回? true ，而? true? 與任何布爾值的? or? 運(yùn)算的結(jié)果都是? true ，那么無(wú)論正確密碼是什么“ Password='1'?or?'1'='1' ”的計(jì)算值永遠(yuǎn)是? true ，這樣惡意攻擊者就可以使用任何帳戶(hù)登錄系統(tǒng)了。這樣的漏洞就被稱(chēng)作“ SQL? 注入漏洞（ SQL?Injection ）”。

　　對(duì)付? SQL? 注入漏洞有兩種方式：過(guò)濾敏感字符和使用參數(shù)化? SQL 。?

　　1). 過(guò)濾敏感字符

　　過(guò)濾敏感字符的思路非常簡(jiǎn)單，由于惡意攻擊者一般需要在輸入框中輸入的文本一般含有? or 、 and 、 select 、 delete? 之類(lèi)的字符串片段，所以在拼接? SQL? 之前檢查用戶(hù)提交的文本中是否含有這些敏感字符串，如果含有則終止操作。

　　2).使用參數(shù)化 SQL

　　為運(yùn)行時(shí)才能確定的用戶(hù)名和密碼設(shè)置了占位符，然后在運(yùn)行時(shí)再設(shè)定占位符的值，在執(zhí)行時(shí)? Java 、 C# 會(huì)直接將參數(shù)化? SQL? 以及對(duì)應(yīng)的參數(shù)值傳遞給? DBMS ，在? DBMS? 中會(huì)將參數(shù)值當(dāng)成一個(gè)普通的值來(lái)處理而不是將它們拼接到參數(shù)化? SQL? 中 ，因此從根本上避免了? SQL? 注入漏洞攻擊。

?

2.?SQL? 調(diào)優(yōu)?

　　在使用? DBMS? 時(shí)經(jīng)常對(duì)系統(tǒng)的性能有非常高的要求：不能占用過(guò)多的系統(tǒng)內(nèi)存和 CPU? 資源、要盡可能快的完成的數(shù)據(jù)庫(kù)操作、要有盡可能高的系統(tǒng)吞吐量。如果系統(tǒng)開(kāi)發(fā)出來(lái)不能滿(mǎn)足要求的所有性能指標(biāo)，則必須對(duì)系統(tǒng)進(jìn)行調(diào)整，這個(gè)工作被稱(chēng)為調(diào)優(yōu)。

　　SQL? 調(diào)優(yōu)的基本原則???

　　“二八原理”是一個(gè)普遍的真理，特別是在計(jì)算機(jī)的世界中表現(xiàn)的更加明顯，那就是? 20% 的代碼的資源消耗占用了? 80% 的總資源消耗。 SQL? 語(yǔ)句也是一種代碼，因此它也符合這個(gè)原理。在進(jìn)行? SQL? 調(diào)優(yōu)的時(shí)候應(yīng)該把主要精力放到這? 20% 的最消耗系統(tǒng)資源的? SQL? 語(yǔ)句中，不要想把所有的? SQL? 語(yǔ)句都調(diào)整到最優(yōu)狀態(tài)。???

索引是數(shù)據(jù)庫(kù)調(diào)優(yōu)的最根本的優(yōu)化方法。

　　常用的 SQL 調(diào)優(yōu)方法：

　　1)? 創(chuàng)建必要的索引

　　2)?使用預(yù)編譯查詢(xún)?

　　程序中通常是根據(jù)用戶(hù)的輸入來(lái)動(dòng)態(tài)執(zhí)行? SQL? 語(yǔ)句，這時(shí)應(yīng)該盡量使用參數(shù)化 SQL ，這樣不僅可以避免? SQL? 注入漏洞攻擊，最重要數(shù)據(jù)庫(kù)會(huì)對(duì)這些參數(shù)化? SQL? 執(zhí)行預(yù)編譯。

　　3)?調(diào)整? WHERE? 子句中的連接順序?

　　DBMS? 一般采用自下而上的順序解析? WHERE? 子句，根據(jù)這個(gè)原理 , 表連接最好寫(xiě)在其他? WHERE? 條件之前，那些可以過(guò)濾掉最大數(shù)量記錄。?

　　比如下面的? SQL? 語(yǔ)句性能較差：? SELECT?*???FROM?T_Person?WHERE???FSalary?>?50000??AND?????FPosition=? ‘ MANAGER ’?? AND?????25?<?(SELECT?COUNT(*)?FROM?T_Manager?WHERE?FManagerId=2);??

　　我們將子查詢(xún)的條件放到最前面，下面的? SQL? 語(yǔ)句性能比較好：? SELECT?*???FROM?T_Person?WHERE???25?<?(SELECT?COUNT(*)?FROM?T_Manager?WHERE?FManagerId=2)?AND?FSalary?>?50000??AND?????FPosition=? ‘ MANAGER ’? ;?

　　4)?SELECT? 語(yǔ)句中避免使用 '*'?

　　SELECT??* 比較簡(jiǎn)單，但是除非確實(shí)需要檢索所有的列，否則將會(huì)檢索出不需要的列，這回增加網(wǎng)絡(luò)的負(fù)載和服務(wù)器的資源消耗；即使確實(shí)需要檢索所有列，也不要使用 SELECT?* ，因?yàn)檫@是一個(gè)非常低效的方法， DBMS? 在解析的過(guò)程中，會(huì)將 * 依次轉(zhuǎn)換成所有的列名，這意味著將耗費(fèi)更多的時(shí)間。

　　5)?盡量將多條? SQL? 語(yǔ)句壓縮到一句? SQL? 中

　　每次執(zhí)行? SQL? 的時(shí)候都要建立網(wǎng)絡(luò)連接、進(jìn)行權(quán)限校驗(yàn)、進(jìn)行? SQL? 語(yǔ)句的查詢(xún)優(yōu)化、發(fā)送執(zhí)行結(jié)果，這個(gè)過(guò)程是非常耗時(shí)的，因此應(yīng)該盡量避免過(guò)多的執(zhí)行? SQL? 語(yǔ)句，能夠壓縮到一句? SQL? 執(zhí)行的語(yǔ)句就不要用多條來(lái)執(zhí)行。

　　6)?用? Where? 子句替換? HAVING? 子句??

　　避免使用? HAVING? 子句，因?yàn)? HAVING?? 只會(huì)在檢索出所有記錄之后才對(duì)結(jié)果集進(jìn)行過(guò)濾。如果能通過(guò)? WHERE? 子句限制記錄的數(shù)目，那就能減少這方面的開(kāi)銷(xiāo)。 HAVING?? 中的條件一般用于聚合函數(shù)的過(guò)濾，除此而外，應(yīng)該將條件寫(xiě)在? WHERE? 子句中。?

　　7)?使用表的別名?

　　當(dāng)在? SQL? 語(yǔ)句中連接多個(gè)表時(shí)，請(qǐng)使用表的別名并把別名前綴于每個(gè)列名上。這樣就可以減少解析的時(shí)間并減少那些由列名歧義引起的語(yǔ)法錯(cuò)誤。?

　　8)?用? EXISTS? 替代? IN??

　　在查詢(xún)中，為了滿(mǎn)足一個(gè)條件，往往需要對(duì)另一個(gè)表進(jìn)行聯(lián)接，在這種情況下，使用? EXISTS? 而不是? IN? 通常將提高查詢(xún)的效率，因?yàn)? IN? 子句將執(zhí)行一個(gè)子查詢(xún)內(nèi)部的排序和合并。

　　9)?用表連接替換? EXISTS???

　　通常來(lái)說(shuō)，表連接的方式比? EXISTS? 更有效率，因此如果可能的話盡量使用表連接替換? EXISTS 。

　　10)?避免在索引列上使用計(jì)算?

　　在? WHERE? 子句中，如果索引列是計(jì)算或者函數(shù)的一部分， DBMS? 的優(yōu)化器將不會(huì)使用索引而使用全表掃描。

　　11)?用? UNION?ALL?? 替換? UNION??

　　當(dāng)? SQL? 語(yǔ)句需要? UNION? 兩個(gè)查詢(xún)結(jié)果集合時(shí)，即使檢索結(jié)果中不會(huì)有重復(fù)的記錄，如果使用? UNION? 這兩個(gè)結(jié)果集同樣會(huì)嘗試進(jìn)行合并，然后在輸出最終結(jié)果前進(jìn)行排序。?因此，如果檢索結(jié)果中不會(huì)有重復(fù)的記錄的話，應(yīng)該用? UNION?ALL? 替代? UNION ，這樣效率就會(huì)因此得到提高。

　　12)?避免隱式類(lèi)型轉(zhuǎn)換造成的全表掃描?

　　13)?防止檢索范圍過(guò)寬???

　　如果? DBMS? 優(yōu)化器認(rèn)為檢索范圍過(guò)寬，那么它將放棄索引查找而使用全表掃描。下面是幾種可能造成檢索范圍過(guò)寬的情況：?使用? IS?NOT?NULL? 或者不等于判斷，可能造成優(yōu)化器假設(shè)匹配的記錄數(shù)太多。?使用? LIKE? 運(yùn)算符的時(shí)候， "a%" 將會(huì)使用索引，而 "a%c" 和 "%c" 則會(huì)使用全表掃描，因此 "a%c" 和 "%c" 不能被有效的評(píng)估匹配的數(shù)量。?

　　如果您有什么問(wèn)題，歡迎在下面評(píng)論，我們一起討論，謝謝~

　　如果您覺(jué)得還不錯(cuò)，不妨點(diǎn)下右下方的推薦，有您的鼓勵(lì)我會(huì)繼續(xù)努力的~

?

讀書(shū)筆記之SQL注入漏洞和SQL調(diào)優(yōu)