容易忽視的十大SQL最佳化方案！

　　SQL效能問題已經逐步發展成為資料庫效能的首要問題，80%的資料庫效能問題都是因SQL而導致。面對日益增多的SQL效能問題，如何下手以及如何提前稽核已經成為越來越多的程式設計師必須要考慮的問題。小千總結了一些容易忽視的幾個SQL最佳化方案，大家一起交流學習!

　　 一、避免進行null判斷

　　應儘量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，這裡不要給資料庫留NULL，儘可能的使用 NOT NULL填充資料庫。

　　備註、描述、評論之類的可以設定為 NULL，不要使用NULL。不要錯誤的認為NULL 不需要空間，如char(100) 型，在欄位建立時，空間就固定了。不管是否插入值(NULL也包含在內)，都是佔用 100個字元的空間的，如果是varchar這樣的變長欄位， null 不佔用空間。可以在num上設定預設值0，確保表中num列沒有null值。

　　 二、不要使用select *

　　使用select *的話會增加解析的時間，另外也會把不需要的資料同時查詢出來，從而延長資料傳輸時間，耗費精力。如text型別的欄位，通常用來儲存一些內容比較繁雜的東西，如果使用select *，則會把該欄位也查詢出來。

　　 三、謹慎使用模糊查詢

　　當模糊匹配以%開頭時，該列索引將失效。若不以%開頭，該列索引有效。

　　 四、不要使用列號

　　使用列號的話，將會增加不必要的解析時間。

　 　五、優先使用UNION ALL，避免使用UNION

　　因為UNION 會將各查詢子集的記錄做比較，故比起UNION ALL ，通常速度都會慢上許多。一般來說，如果使用UNION ALL能滿足要求的話，務必使用UNION ALL。還有一種情況，如果業務上能夠確保不會出現重複記錄。

　　 六、在where語句或者order by語句中避免對索引欄位進行計算操作

　　當在索引列上進行操作之後，索引將會失效。正確做法應該是將值計算好再傳入進來。

　　 七、使用not exist代替not in

　　如果查詢語句使用了not in 那麼內外表都進行全表掃描，沒有用到索引;而not extsts 的子查詢依然能用到表上的索引。

　　 八、exist和in的區別

　　in 是把外表和內表作hash 連線，而exists是對外表作loop迴圈，每次loop迴圈

　　再對內表進行查詢。因此，in用到的是外表的索引， exists用到的是內表的索引。如果查詢的兩個表大小相當，那麼用in和exists差別不大。如果兩個表中一個較小，一個是大表，則子查詢表大的用exists，子查詢表小的用in。

　 　九、避免在索引列上做如下操作

　　1.避免在索引列上使用IS NULL和IS NOT NULL。

　　2.避免在索引列上出現資料型別轉換。(比如某欄位是String型別，引數傳入時是int型別)當在索引列上使用如上操作時，索引將會失效，造成全表掃描。

　 　十、複雜操作可以考慮適當拆成幾步

　　有時候會有透過一個SQL語句來實現複雜業務的例子出現，為了實現複雜的業務，巢狀多級子查詢。造成SQL效能問題。對於這種情況可以考慮拆分SQL，透過多個SQL語句實現，或者把部分程式能完成的工作交給程式完成。