SQL這樣幹就是在給自己刨坑
儘量少用負向條件查詢
假設我們有一個Order表，表中有一個欄位是Status，這個欄位有4個值，分別是0=待支付、1=待發貨、2=待收貨、3=已完成。
這時，我們要查詢所有已經支付的訂單，很多人就會寫這樣的SQL：
select * from Order where Status != 0
- 這就是一個不好的習慣了。負向條件查詢（例如：!=、not in、not exists）都是不能使用索引的，當Order表中的資料到達一定量級時，這個查詢的效率會急劇的下降。
所以，正確的寫法應該是：
select * from Order where Status in (1,2,3)
儘量少用前導模糊查詢
假設我們現在要根據使用者的訂單號（OrderNo）查詢使用者的訂單，如果是直接通過SQL查詢的話，儘量不要使用前導模糊查詢，也就是：
select * from Order where OrderNo like '%param'
select * from Order where OrderNo like '%param%'
- 因為，前導模糊查詢是無法命中索引的，所以，會整個資料庫去檢索，效率相當的差，而非前導模糊查詢則是可以使用索引的。
因此，我們儘量不要把萬用字元放在前面，改成下面這樣：
select * from Order where OrderNo like 'param%'
儘量不要在條件欄位上進行運算
假設，現在有一個需求，是要查詢2018年全年的訂單資料，我們就需要通過建立時間（CreateTime）來進行檢索，但是，有些程式設計師就喜歡這樣寫SQL：
select * from Order where Year(CreateTime)=2018
然後，每次執行時就會發現，查詢的速度異常的慢，導致了大量的請求掛起甚至超時。這是因為，我們即使在CreateTime上建立了索引，但是，如果使用了運算函式，查詢一樣會進行全表的檢索。
所以，我們可以改成這樣：
select * from Order where CreateTime > '2018-1-1 00:00:00'
當查詢允許Null值的列時，需要特別注意
我們在建立表的欄位時，如果這個欄位需要作為索引時，儘量不要允許Null。因為，單列索引不會存Null值，複合索引不存所有索引列都為Null的值，所以如果列允許為Null，可能會得到“不符合預期”的結果集。
例如：我們有一個User表，其中有UserName欄位記錄了使用者的名字，並且添加了索引。
| user |
|---|
| userid | username |
|---|---|
| 1 | 小倩 |
| 2 | Null |
| 3 | 小明 |
| 4 | 小紅 |
現在我們執行了這樣一個查詢：
select * from User where UserName != '小倩'
但結果是這樣的
| 3 | 小明 |
|---|---|
| 4 | 小紅 |
- 那位UserName為Null的資料並沒有能包括進來。因此，如果我們想要包含這個使用者的話，最好能夠設定一個預設值。
複合索引，使用時要注意順序
登入，肯定是我們使用得最多的一個查詢了，為了保證效率，我們為LoginID和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}'
- 查詢時，確無法命中索引，這是什麼原因呢？
這是由於，複合索引對於查詢的順序是非常的銘感的，所以，符合索引中包含了幾種規則，其中就有全列匹配和最左字首匹配。
當所有列都能夠匹配時，雖然查詢的順序上有不同，但是查詢優化器會將順序進行調整，以滿足適合索引的順序，所以，順序的顛倒是沒有問題的。
但是，如果所有列不能匹配時，就必須滿足最左字首匹配了，也就是，必須按照從左到右的順序進行排列。因此，當我們建立是索引是<LoginID, Password>時，where Password = ‘{Password}’ 就不滿足最左字首規則，無法命中索引了。
結果唯一時，別悶著
通常，我們設計User表時，並不會把LoginID作為主鍵，但是，LoginID確會在業務邏輯中驗證唯一性，因此，如果使用
select * from User where LoginID = '{LoginID}'
查詢時，結果一定只有一條。但是，資料庫是不知道的，即使找到了這唯一的一條結果，他也會一直繼續，直到掃描完所有的資料。
因此，在執行這樣的查詢時，我們可以優化一下，改成：
select * from User where LoginID = '{LoginID}' limit 1
最後，上面所有的例子都是坑
儘量少用或別用Select ，我們的查詢其實都是有目的的，就好像登入一樣，我們其實只需要知道有結果返回就行了，使用select count()就可以了，但是我們使用select * 的話，就會消耗大量無效的資料庫記憶體。