SQL這樣幹，你就是給本身刨坑.....

SQL是做爲一個程序員接觸得很是多的一種語言，可是，不少時候，咱們會發現，有些SQL的執行效率異常的差，形成了數據庫的負擔。咱們經過分析這些有問題的SQL，就能夠發現不少咱們平時在寫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，可能會獲得「不符合預期」的結果集。

這裏推薦一下個人Java後端高級技術羣：479499375 ，羣裏有（Java高架構、分佈式架構、高可擴展、高性能、高併發、性能優化、Spring boot、Redis、ActiveMQ、等學習資源）進羣免費送給每一位Java小夥伴，無論你是轉行，仍是工做中想提高本身能力均可以！

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

 

 

如今咱們執行了這樣一個查詢：

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

但結果是這樣的

 

 

那位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(0)就能夠了，可是咱們使用select * 的話，就會消耗大量無效的數據庫內存。