SQL是作為一個程序員接觸得非常多的一種語言，但是，很多時候，我們會發(fā)現(xiàn)，有些SQL的執(zhí)行效率異常的差，造成了數(shù)據(jù)庫的負擔。我們通過分析這些有問題的SQL，就可以發(fā)現(xiàn)很多我們平時在寫SQL的時候忽略的問題。

今天，我們就來講一下這些需要改掉的壞習慣。

盡量少用負向條件查詢

假設我們有一個Order表，表中有一個字段是Status，這個字段有4個值，分別是0=待支付、1=待發(fā)貨、2=待收貨、3=已完成。

這時，我們要查詢所有已經(jīng)支付的訂單，很多人就會寫這樣的SQL： 

select * from Order where Status != 0 

這就是一個不好的習慣了。負向條件查詢(例如：!=、not in、not exists)都是不能使用索引的，當Order表中的數(shù)據(jù)到達一定量級時，這個查詢的效率會急劇的下降。

所以，正確的寫法應該是： 

select * from Order where Status in (1,2,3) 

盡量少用前導模糊查詢

假設我們現(xiàn)在要根據(jù)用戶的訂單號(OrderNo)查詢用戶的訂單，如果是直接通過SQL查詢的話，盡量不要使用前導模糊查詢，也就是： 

select * from Order where OrderNo like '%param' 

或者 

select * from Order where OrderNo like '%param%' 

因為，前導模糊查詢是無法***索引的，所以，會整個數(shù)據(jù)庫去檢索，效率相當?shù)牟睿乔皩：樵儎t是可以使用索引的。 

因此，我們盡量不要把通配符放在前面，改成下面這樣： 

select * from Order where OrderNo like 'param%'  

盡量不要在條件字段上進行運算

假設，現(xiàn)在有一個需求，是要查詢2018年全年的訂單數(shù)據(jù)，我們就需要通過創(chuàng)建時間(CreateTime)來進行檢索，但是，有些程序員就喜歡這樣寫SQL： 

select * from Order where Year(CreateTime)=2018 

然后，每次執(zhí)行時就會發(fā)現(xiàn)，查詢的速度異常的慢，導致了大量的請求掛起甚至超時。這是因為，我們即使在CreateTime上建立了索引，但是，如果使用了運算函數(shù)，查詢一樣會進行全表的檢索。 

所以，我們可以改成這樣： 

select * from Order where CreateTime > '2018-1-1 00:00:00' 

當查詢允許Null值的列時，需要特別注意

我們在創(chuàng)建表的字段時，如果這個字段需要作為索引時，盡量不要允許Null。因為，單列索引不會存Null值，復合索引不存所有索引列都為Null的值，所以如果列允許為Null，可能會得到“不符合預期”的結果集。

例如：我們有一個User表，其中有UserName字段記錄了用戶的名字，并且添加了索引。

[[246447]] 

現(xiàn)在我們執(zhí)行了這樣一個查詢： 

select * from User where UserName != '小倩' 

但結果是這樣的 

那位UserName為Null的數(shù)據(jù)并沒有能包括進來。因此，如果我們想要包含這個用戶的話，***能夠設置一個默認值。

復合索引，使用時要注意順序

登錄，肯定是我們使用得最多的一個查詢了，為了保證效率，我們?yōu)長oginID和Password加上了復合索引。

當我們使用 

select * from User where LoginID = '{LoginID}' and Password = '{Password}'select * from User where Password = '{Password}' and LoginID = '{LoginID}' 

查詢時，都是能夠準備的***索引。當我們使用： 

select * from User where LoginID = '{LoginID}' 

查詢時，也是能夠***索引的。但是，當我們使用 

select * from User where Password = '{Password}' 

查詢時，確無法***索引，這是什么原因呢?

這是由于，復合索引對于查詢的順序是非常的銘感的，所以，符合索引中包含了幾種規(guī)則，其中就有全列匹配和最左前綴匹配。

當所有列都能夠匹配時，雖然查詢的順序上有不同，但是查詢優(yōu)化器會將順序進行調整，以滿足適合索引的順序，所以，順序的顛倒是沒有問題的。 

但是，如果所有列不能匹配時，就必須滿足最左前綴匹配了，也就是，必須按照從左到右的順序進行排列。因此，當我們建立是索引是

結果唯一時，別悶著

通常，我們設計User表時，并不會把LoginID作為主鍵，但是，LoginID確會在業(yè)務邏輯中驗證唯一性，因此，如果使用 

select * from User where LoginID = '{LoginID}' 

查詢時，結果一定只有一條。但是，數(shù)據(jù)庫是不知道的，即使找到了這唯一的一條結果，他也會一直繼續(xù)，直到掃描完所有的數(shù)據(jù)。

因此，在執(zhí)行這樣的查詢時，我們可以優(yōu)化一下，改成： 

select * from User where LoginID = '{LoginID}' limit 1 

這樣，當查詢到結果時，就不會再繼續(xù)了。

***，上面所有的例子都是坑

盡量少用或別用Select *，我們的查詢其實都是有目的的，就好像登錄一樣，我們其實只需要知道有結果返回就行了，使用select count(0)就可以了，但是我們使用select * 的話，就會消耗大量無效的數(shù)據(jù)庫內存。