MySQL優化之Explain命令解讀

簡述:　　

　　explain爲mysql提供語句的執行計劃信息。能夠應用在select、delete、insert、update和place語句上。explain的執行計劃，只是做爲語句執行過程的一個參考，實際執行的過程不必定和計劃徹底一致，可是執行計劃中透露出的訊息卻能夠幫助選擇更好的索引和寫出更優化的查詢語句。

---

EXPLAIN輸出項（可參考mysql5.7文檔）

備註:當使用FORMAT=JSON， 返回的數據爲json結構時，JSON Name爲null的不顯示。(參考文檔：https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain-output-columns)

Column	JSON Name	Meaning
id	select_id	The SELECT identifier
select_type	None	The SELECT type
table	table_name	The table for the output row
partitions	partitions	The matching partitions
type	access_type	The join type
possible_keys	possible_keys	The possible indexes to choose
key	key	The index actually chosen
key_len	key_length	The length of the chosen key
ref	ref	The columns compared to the index
rows	rows	Estimate of rows to be examined
filtered	filtered	Percentage of rows filtered by table condition
Extra	None	Additional information

注意：在5.7之前的版本中，想要顯示partitions須要使用explain partitions命令；想要顯示filtered須要使用explain extended命令。在5.7版本後，默認explain直接顯示partitions和filtered中的信息。
下面說明一下各列含義及可能值：

---

 

一、id的含義

　　The SELECT identifier. This is the sequential number of the SELECT within the query. The value can be NULL if the row refers to the union result of other rows. In this case, the table column shows a value like <unionM,N> to indicate that the row refers to the union of the rows with id values of M and N.
翻譯：id爲SELECT的標識符。它是在SELECT查詢中的順序編號。若是這一行表示其餘行的union結果，這個值能夠爲空。在這種狀況下，table列會顯示爲形如<union M,N>，表示它是id爲M和N的查詢行的聯合結果。

　　注意：id列數字越大越先執行，若是說數字同樣大，那麼就從上往下依次執行。

---

二、select_type可能出現的狀況（來源於Mysql5.7文檔）

select_type Value	JSON Name	Meaning
SIMPLE	None	Simple SELECT (not using UNION or subqueries)
PRIMARY	None	Outermost SELECT
UNION	None	Second or later SELECT statement in a UNION
DEPENDENT UNION	dependent (true)	Second or later SELECT statement in a UNION, dependent on outer query
UNION RESULT	union_result	Result of a UNION.
SUBQUERY	None	First SELECT in subquery
DEPENDENT SUBQUERY	dependent (true)	First SELECT in subquery, dependent on outer query
DERIVED	None	Derived table SELECT (subquery in FROM clause)
MATERIALIZED	materialized_from_subquery	Materialized subquery
UNCACHEABLE SUBQUERY	cacheable (false)	A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query
UNCACHEABLE UNION	cacheable (false)	The second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY)

各項內容含義說明：
A：simple：表示不須要union操做或者不包含子查詢的簡單select查詢。有鏈接查詢時，外層的查詢爲simple，且只有一個。
B：primary：一個須要union操做或者含有子查詢的select，位於最外層的單位查詢的select_type即爲primary。且只有一個。
C：union：union鏈接的select查詢，除了第一個表外，第二個及之後的表select_type都是union。
D：dependent union：與union同樣，出如今union 或union all語句中，可是這個查詢要受到外部查詢的影響
E：union result：包含union的結果集，在union和union all語句中,由於它不須要參與查詢，因此id字段爲null
F：subquery：除了from字句中包含的子查詢外，其餘地方出現的子查詢均可能是subquery
G：dependent subquery：與dependent union相似，表示這個subquery的查詢要受到外部表查詢的影響
H：derived：from字句中出現的子查詢。
I：materialized：被物化的子查詢
J：UNCACHEABLE SUBQUERY：對於外層的主表，子查詢不可被物化，每次都須要計算（耗時操做）
K：UNCACHEABLE UNION：UNION操做中，內層的不可被物化的子查詢（相似於UNCACHEABLE SUBQUERY）

---

 

三、table

　　顯示的查詢表名，若是查詢使用了別名，那麼這裏顯示的是別名，若是不涉及對數據表的操做，那麼這顯示爲null，若是顯示爲尖括號括起來的<derived N>就表示這個是臨時表，後邊的N就是執行計劃中的id，表示結果來自於這個查詢產生。若是是尖括號括起來的<union M,N>，與<derived N>相似，也是一個臨時表，表示這個結果來自於union查詢的id爲M,N的結果集。若是是尖括號括起來的<subquery N>，這個表示子查詢結果被物化，以後子查詢結果能夠被複用（我的理解）。

---

 

四、type

　　依次從好到差：system，const，eq_ref，ref，fulltext，ref_or_null，index_merge，unique_subquery，index_subquery，range，index，ALL，除了all以外，其餘的type均可以使用到索引，除了index_merge以外，其餘的type只能夠用到一個索引
A：system：表中只有一行數據或者是空表，且只能用於myisam和memory表。若是是Innodb引擎表，type列在這個狀況一般都是all或者index
B：const：使用惟一索引或者主鍵，返回記錄必定是1行記錄的等值where條件時，一般type是const。其餘數據庫也叫作惟一索引掃描
C：eq_ref：出如今要鏈接過個表的查詢計劃中，驅動表只返回一行數據，且這行數據是第二個表的主鍵或者惟一索引，且必須爲not null，惟一索引和主鍵是多列時，只有全部的列都用做比較時纔會出現eq_ref
D：ref：不像eq_ref那樣要求鏈接順序，也沒有主鍵和惟一索引的要求，只要使用相等條件檢索時就可能出現，常見與輔助索引的等值查找。或者多列主鍵、惟一索引中，使用第一個列以外的列做爲等值查找也會出現，總之，返回數據不惟一的等值查找就可能出現。
E：fulltext：全文索引檢索，要注意，全文索引的優先級很高，若全文索引和普通索引同時存在時，mysql無論代價，優先選擇使用全文索引
F：ref_or_null：與ref方法相似，只是增長了null值的比較。實際用的很少。
例如：
SELECT * FROM ref_table
WHERE key_column=expr OR key_column IS NULL;
G：index_merge：表示查詢使用了兩個以上的索引，最後取交集或者並集，常見and ，or的條件使用了不一樣的索引，官方排序這個在ref_or_null以後，可是實際上因爲要讀取所個索引，性能可能大部分時間都不如range
H：unique_subquery：用於where中的in形式子查詢，子查詢返回不重複值惟一值
I：index_subquery：用於in形式子查詢使用到了輔助索引或者in常數列表，子查詢可能返回重複值，可使用索引將子查詢去重。
J：range：索引範圍掃描，常見於使用 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, IN()或者like等運算符的查詢中。
K：index：索引全表掃描，把索引從頭至尾掃一遍，常見於使用索引列就能夠處理不須要讀取數據文件的查詢、可使用索引排序或者分組的查詢。按照官方文檔的說法：

● If the index is a covering index for the queries and can be used to satisfy all data required from the table, only the index tree is scanned. In this case, the Extracolumn says Using index. An index-only scan usually is faster than ALL because the size of the index usually is smaller than the table data.
● A full table scan is performed using reads from the index to look up data rows in index order. Uses index does not appear in the Extra column.

　　以上說的是索引掃描的兩種狀況，一種是查詢使用了覆蓋索引，那麼它只須要掃描索引就能夠得到數據，這個效率要比全表掃描要快，由於索引一般比數據表小，並且還能避免二次查詢。在extra中顯示Using index，反之，若是在索引上進行全表掃描，沒有Using index的提示。

---

 

五、partitions

版本5.7之前，該項是explain partitions顯示的選項，5.7之後成爲了默認選項。該列顯示的爲分區表命中的分區狀況。非分區表該字段爲空（null）。

---

 

六、possible_keys

查詢可能使用到的索引都會在這裏列出來。

---

 

七、key

查詢真正使用到的索引，select_type爲index_merge時，這裏可能出現兩個以上的索引，其餘的select_type這裏只會出現一個。

---

 

八、key_len

用於處理查詢的索引長度，若是是單列索引，那就整個索引長度算進去，若是是多列索引，那麼查詢不必定都能使用到全部的列，具體使用到了多少個列的索引，這裏就會計算進去，沒有使用到的列，這裏不會計算進去。留意下這個列的值，算一下你的多列索引總長度就知道有沒有使用到全部的列了。要注意，mysql的ICP特性使用到的索引不會計入其中。另外，key_len只計算where條件用到的索引長度，而排序和分組就算用到了索引，也不會計算到key_len中。

---

 

九、ref

若是是使用的常數等值查詢，這裏會顯示const，若是是鏈接查詢，被驅動表的執行計劃這裏會顯示驅動表的關聯字段，若是是條件使用了表達式或者函數，或者條件列發生了內部隱式轉換，這裏可能顯示爲func。

---

 

十、rows

這裏是執行計劃中估算的掃描行數，不是精確值

---

 

十一、extra

對於extra列，官網上有這樣一段話：

If you want to make your queries as fast as possible, look out for Extra column values of Using filesort and Using temporary, or, in JSON-formatted EXPLAINoutput, for using_filesort and using_temporary_table properties equal to true.

大概的意思就是說，若是你想要優化你的查詢，那就要注意extra輔助信息中的using filesort和using temporary，這兩項很是消耗性能，須要注意。

這個列能夠顯示的信息很是多，有幾十種，經常使用的有：
A：distinct：在select部分使用了distinc關鍵字。
B：no tables used：不帶from字句的查詢或者From dual查詢。
C：使用not in()形式子查詢或not exists運算符的鏈接查詢，這種叫作反鏈接。即，通常鏈接查詢是先查詢內表，再查詢外表，反鏈接就是先查詢外表，再查詢內表。
D：using filesort：排序時沒法使用到索引時，就會出現這個。常見於order by和group by語句中。
E：using index：查詢時不須要回表查詢，直接經過索引就能夠獲取查詢的數據。
F：using join buffer（block nested loop），using join buffer（batched key accss）：5.6.x以後的版本優化關聯查詢的BNL，BKA特性。主要是減小內表的循環數量以及比較順序地掃描查詢。
G：using sort_union，using_union，using intersect，using sort_intersection：
　　using intersect：表示使用and的各個索引的條件時，該信息表示是從處理結果獲取交集。
　　using union：表示使用or鏈接各個使用索引的條件時，該信息表示從處理結果獲取並集。
　　using sort_union和using sort_intersection：與前面兩個對應的相似，只是他們是出如今用and和or查詢信息量大時，先查詢主鍵，而後進行排序合併後，才能讀取記錄並返回。
H：using temporary：表示使用了臨時表存儲中間結果。臨時表能夠是內存臨時表和磁盤臨時表，執行計劃中看不出來，須要查看status變量，used_tmp_table，used_tmp_disk_table才能看出來。
I：using where：表示存儲引擎返回的記錄並非全部的都知足查詢條件，須要在server層進行過濾。查詢條件中分爲限制條件和檢查條件，5.6以前，存儲引擎只能根據限制條件掃描數據並返回，而後server層根據檢查條件進行過濾再返回真正符合查詢的數據。5.6.x以後支持ICP特性，能夠把檢查條件也下推到存儲引擎層，不符合檢查條件和限制條件的數據，直接不讀取，這樣就大大減小了存儲引擎掃描的記錄數量。extra列顯示using index condition。
J：firstmatch(tb_name)：5.6.x開始引入的優化子查詢的新特性之一，常見於where字句含有in()類型的子查詢。若是內表的數據量比較大，就可能出現這個。
K：loosescan(m..n)：5.6.x以後引入的優化子查詢的新特性之一，在in()類型的子查詢中，子查詢返回的可能有重複記錄時，就可能出現這個。

---

 

十二、filtered

　　使用explain extended時會出現這個列，5.7以後的版本默認就有這個字段，不須要使用explain extended了。這個字段表示存儲引擎返回的數據在server層過濾後，剩下多少知足查詢的記錄數量的比例，注意是百分比，不是具體記錄數。