19 個讓 MySQL 效率提升 3 倍的 SQL 優化技巧

優化成本:

硬件>系統配置>數據庫表結構>SQL及索引

優化效果:

硬件<系統配置<數據庫表結構<SQL及索引

 

本文咱們就來談談 MySQL 中經常使用的 SQL 優化方法，利用好這些方法會讓你的 MySQL 效率提升提高至少 3 倍。

一、EXPLAIN

作 MySQL 優化，咱們要善用 EXPLAIN 查看 SQL 執行計劃。

•Type 列，鏈接類型。一個好的 SQL 語句至少要達到 Range 級別。杜絕出現 All 級別。

•Key 列，使用到的索引名。若是沒有選擇索引，值是 NULL。能夠採起強制索引方式。

•Key_Len 列，索引長度。

•Rows 列，掃描行數。該值是個預估值。

•Extra 列，詳細說明。注意，常見的不太友好的值，以下：Using filesort，Using temporary。

二、SQL 語句中 IN 包含的值不該過多

MySQL 對於 IN 作了相應的優化，即將 IN 中的常量所有存儲在一個數組裏面，並且這個數組是排好序的。可是若是數值較多，產生的消耗也是比較大的。

再例如：Select Id From T where Num IN (1,2,3) 對於連續的數值，能用 Between 就不要用 IN 了；再或者使用鏈接來替換。

三、Select 語句務必指明字段名稱

Select * 會增長不少沒必要要的消耗（如：CPU、IO、內存、網絡帶寬等）, 增長了使用覆蓋索引的可能性。

當表結構發生改變時，前斷也須要更新。因此要求直接在 Select 後面接上字段名。

四、當只須要一條數據的時候，使用 Limit 1

這是爲了使 EXPLAIN 中 Type 列達到 Const 類型。

五、若是排序字段沒有用到索引，就儘可能少排序

六、若是限制條件中其餘字段沒有索引，儘可能少用 OR

OR 兩邊的字段中，若是有一個不是索引字段，而其餘條件也不是索引字段，會形成該查詢不走索引的狀況。不少時候使用 Union All 或者是 Union（必要的時候）的方式來代替 OR 會獲得更好的效果。

七、儘可能用 Union All 代替 Union

Union 和 Union All 的差別主要是前者須要將結果集合並後再進行惟一性過濾操做，這就會涉及到排序，增長大量的 CPU 運算，加大資源消耗及延遲。固然，Union All 的前提條件是兩個結果集沒有重複數據。

八、不使用 ORDER BY RAND()

Select Id From `dynamic` Order By rand() Limit 1000;

上面的 SQL 語句，可優化爲：

Select Id From `dynamic` T1 Join (Select rand() * (Select Max(Id) From `dynamic`) as nid) T2 on T1.Id > T2.nidlimit 1000

九、區分 IN 和 Exists、Not In 和 Not Exists

Select * From 表A Where Id IN (Select Id From 表B)

上面 SQL 語句至關於

Select * From 表A Where Exists(Select * From 表B Where 表B.Id=表A.Id)

區分 IN 和 Exists 主要是形成了驅動順序的改變（這是性能變化的關鍵）。若是是 Exists，那麼之外層表爲驅動表，先被訪問，若是是 IN，那麼先執行子查詢。因此 IN 適合於外表大而內表小的狀況，Exists 適合於外表小而內表大的狀況。

關於 Not IN 和 Not Exists，推薦使用 Not exists。這不只僅是效率問題，Not IN 可能存在邏輯問題。

如何高效的寫出一個替代 not in 的 SQL 語句？

原 SQL 語句：

Select Colname … From A 表 Where A.id Not IN (Select B.id From B表)

高效的 SQL 語句：

Select Colname … From A表 Left join B表 ON Where A.id = B.id Where B.id is Null

十、使用合理的分頁方式以提升分頁的效率

Select Id,Name From Product Limit 866613, 20

使用上述 SQL 語句作分頁的時候，可能有人會發現，隨着表數據量的增長，直接使用 Limit 分頁查詢會愈來愈慢。

優化的方法以下：能夠取前一頁的最大行數的 Id ，而後根據這個最大的 Id 來限制下一頁的起點。好比：此列中，上一頁最大的 Id 是 866612。SQL 能夠採用以下的寫法：

Select Id,Name From Product Where Id> 866612 Limit 20

十一、分段查詢

在一些用戶選擇頁面中，可能一些用戶選擇的時間範圍過大，形成查詢緩慢。主要的緣由是掃描行數過多。這個時候能夠經過程序，分段進行查詢，循環遍歷，將結果合併處理進行展現。

十二、避免在 Where 子句中對字段進行 Null 值判斷

對於 Null 的判斷會致使引擎放棄使用索引而進行全表掃描。

1三、不建議使用 % 前綴模糊查詢

例如：Like "%name" 或者 Like "%name%" ，這種查詢會致使索引失效而進行全表掃描。可是可使用 Like "name%"。那如何要查詢 %name% 呢？

1四、避免在 Where 子句中對字段進行表達式操做

好比下面這個例子：

Select user_id,user_project from user_base Where age*2=36;

在上述 SQL 中對字段就好了算術運算，這會形成引擎放棄使用索引，建議改爲：

Select user_id,user_project from user_base where age=36/2;

1五、避免隱式類型轉換

Where 子句中出現 Column 字段的類型和傳入的參數類型不一致的時候發生的類型轉換，建議先肯定 Where 中的參數類型。

1六、對於聯合索引來講，要遵照最左前綴法則

舉列來講：索引含有字段 id、name、school，能夠直接用 id 字段，也能夠 id、name 這樣的順序，可是 name，school 都沒法使用這個索引。因此在建立聯合索引的時候必定要注意索引字段順序，經常使用的查詢字段放在最前面。

1七、必要時可使用 Force Index 來強制查詢走某個索引

有的時候 MySQL 優化器採起它認爲合適的索引來檢索 SQL 語句，可是可能它所採用的索引並非咱們想要的。這時就能夠採用 Force index 來強制優化器使用咱們制定的索引。

1八、注意範圍查詢語句

對於聯合索引來講，若是存在範圍查詢，好比 Between、>、< 等條件時，會形成後面的索引字段失效。

1九、關於 JOIN 優化

LEFT JOIN A 表爲驅動表，INNER JOIN MySQL 會自動找出那個數據少的表做用驅動表，RIGHT JOIN B表爲驅動表。

注意：

•MySQL 中沒有 Full Join ，能夠用如下方式來解決：

Select * from A left join B on B.name = A.namewhere B.name is nullunion allselect * from B;

•儘可能使用 Inner Join，避免 Left Join

參與聯合查詢的表至少爲 2 張表，通常都存在大小之分。若是鏈接方式是 Inner Join，在沒有其餘過濾條件的狀況下 MySQL 會自動選擇小表做爲驅動表。可是 Left Join 在驅動表的選擇上遵循的是左邊驅動右邊的原則，即 Left join 左邊的表名爲驅動表。

•合理利用索引

被驅動表的索引字段做爲 ON 的限制字段。

•利用小表去驅動大表

從原理圖可以直觀的看出若是可以減小驅動表的話，減小嵌套循環中的循環次數，以減小 IO 總量及 CPU 運算的次數。

•巧用 STRAIGHT_JOIN
Inner Join 是由 MySQL 選擇驅動表，可是有些特殊狀況須要選擇另外的表做爲驅動表。好比：Group By、Order By 等 「Using filesort」、「Using temporary」時。

STRAIGHT_JOIN 用來強制鏈接順序，在 STRAIGHT_JOIN 左邊的表名就是驅動表，右邊則是被驅動表。在使用 STRAIGHT_JOIN 有個前提條件是該查詢是內鏈接，也就是 Inner Join。其餘鏈接不推薦使用 STRAIGHT_JOIN，不然可能形成查詢結果不許確。

原文做者：https://mp.weixin.qq.com/s/XlBOTUGmAk54IU_HnsvxLQ