經過Explain查詢和分析SQL的執行計劃

 

索引類型

在 MySQL 中，主要有四種類型的索引，分別爲： B-Tree 索引， Hash 索引， Fulltext 索引和 R-Tree 索引。

 

 

Explain解釋

能夠經過Explain查詢SQL的執行計劃，例子以下：

Explain

explain返回的各列的含義：

 

列	含義
table	顯示查詢是關於哪一個表的
type	很重要的列，顯示鏈接使用了何種類型。從最好到最差的鏈接類型爲const、eq_reg、ref、range、index和ALL
possible_keys	顯示可能應用在這張表中的索引。若是爲空，沒有可能應用的索引
key	實際使用的索引。若是爲NULL，則沒有使用索引
key_len	使用的索引的長度。在不損失精確性的狀況下，長度越短越好
ref	顯示索引的哪一列被使用了
rows	MYSQL認爲必須檢查的用來返回請求的行數
extra	當這一列的值是Using filesort或Using temporary時，說明查詢須要優化了

 

建索引的五大原則

1.最左前綴匹配原則，很是重要的原則，mysql會一直向右匹配直到遇到範圍查詢(>、<、between、like)就中止匹配，好比a = 1 and b = 2 and c > 3 and d = 4 若是創建(a,b,c,d)順序的索引，d是用不到索引的，若是創建(a,b,d,c)的索引則均可以用到，a,b,d的順序能夠任意調整。

 

1. 2.=和in能夠亂序，好比a = 1 and b = 2 and c = 3 創建(a,b,c)索引能夠任意順序，mysql的查詢優化器會幫你優化成索引能夠識別的形式

 

3.儘可能選擇區分度高的列做爲索引,區分度的公式是count(distinct col)/count(*)，表示字段不重複的比例，比例越大咱們掃描的記錄數越少，惟一鍵的區分度是1，而一些狀態、性別字段可能在大數據面前區分度就是0，那可能有人會問，這個比例有什麼經驗值嗎？使用場景不一樣，這個值也很難肯定，通常須要join的字段咱們都要求是0.1以上，即平均1條掃描10條記錄

 

4.索引列不能參與計算，保持列「乾淨」，好比from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，緣由很簡單，b+樹中存的都是數據表中的字段值，但進行檢索時，須要把全部元素都應用函數才能比較，顯然成本太大。因此語句應該寫成create_time = unix_timestamp(’2014-05-29’);

 

5.儘可能的擴展索引，不要新建索引。好比表中已經有a的索引，如今要加(a,b)的索引，那麼只須要修改原來的索引便可

 

回到開始的慢查詢

根據最左匹配原則，最開始的sql語句的索引應該是status、operator_id、type、operate_time的聯合索引；其中status、operator_id、type的順序能夠顛倒，因此我纔會說，把這個表的全部相關查詢都找到，會綜合分析；

好比還有以下查詢

select * from task where status = 0 and type = 12 limit 10;

select count(*) from task where status = 0 ;

那麼索引創建成(status,type,operator_id,operate_time)就是很是正確的，由於能夠覆蓋到全部狀況。這個就是利用了索引的最左匹配的原則

 

 

慢查詢優化基本步驟

0.先運行看看是否真的很慢，注意設置SQL_NO_CACHE

1.where條件單表查，鎖定最小返回記錄表。這句話的意思是把查詢語句的where都應用到表中返回的記錄數最小的表開始查起，單表每一個字段分別查詢，看哪一個字段的區分度最高

2.explain查看執行計劃，是否與1預期一致（從鎖定記錄較少的表開始查詢）

3.order by limit 形式的sql語句讓排序的表優先查

4.瞭解業務方使用場景

5.加索引時參照建索引的幾大原則

6.觀察結果，不符合預期繼續從0分析