MySQL優化之Explain命令解讀，optimizer_trace

阿新 • • 發佈：2019-01-03

簡述:　　

　　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中的資訊。
下面說明一下各列含義及可能值：

1、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列數字越大越先執行，如果說數字一樣大，那麼就從上往下依次執行。

2、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）

3、table

　　顯示的查詢表名，如果查詢使用了別名，那麼這裡顯示的是別名，如果不涉及對資料表的操作，那麼這顯示為null，如果顯示為尖括號括起來的<derived N>就表示這個是臨時表，後邊的N就是執行計劃中的id，表示結果來自於這個查詢產生。如果是尖括號括起來的<union M,N>，與<derived N>類似，也是一個臨時表，表示這個結果來自於union查詢的id為M,N的結果集。如果是尖括號括起來的<subquery N>，這個表示子查詢結果被物化，之後子查詢結果可以被複用（個人理解）。

4、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的提示。

5、partitions

版本5.7以前，該項是explain partitions顯示的選項，5.7以後成為了預設選項。該列顯示的為分割槽表命中的分割槽情況。非分割槽表該欄位為空（null）。

6、possible_keys

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

7、key

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

8、key_len

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

9、ref

如果是使用的常數等值查詢，這裡會顯示const，如果是連線查詢，被驅動表的執行計劃這裡會顯示驅動表的關聯欄位，如果是條件使用了表示式或者函式，或者條件列發生了內部隱式轉換，這裡可能顯示為func。

10、rows

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

11、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()型別的子查詢中，子查詢返回的可能有重複記錄時，就可能出現這個。

12、filtered

　　使用explain extended時會出現這個列，5.7之後的版本預設就有這個欄位，不需要使用explain extended了。這個欄位表示儲存引擎返回的資料在server層過濾後，剩下多少滿足查詢的記錄數量的比例，注意是百分比，不是具體記錄數。

一、explain

　　1.id

　　1.SQL執行順序：從大到小的執行.如果相等先執行上面的，再執行下面的。（id號為sql程式碼中select從左到右出現的順序號）
　　
　　2. select_type就是select型別,可以有以下幾種
　　(1) SIMPLE
　　簡單Select(不使用UNION或子查詢等) 例如:　
程式程式碼
mysql> explain select * from t3 where id=3952602;
　　+----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------+
　　| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
　　+----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------+
　　| 1 | SIMPLE | t3 | const | PRIMARY,idx_t3_id | PRIMARY | 4 | const | 1 | |
　　+----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------+

　　(6).SUBQUERY
　　子查詢中的第一個Select.
程式程式碼
mysql> explain select * from t3 where id = (select id from t3 where id=3952602 ) ;
　　+----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------------+
　　| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
　　+----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------------+
　　| 1 | PRIMARY | t3 | const | PRIMARY,idx_t3_id | PRIMARY | 4 | const | 1 | |
　　| 2 | SUBQUERY | t3 | const | PRIMARY,idx_t3_id | PRIMARY | 4 | | 1 | Using index |
　　+----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------------+

　　例如:
程式程式碼
mysql> explain select * from t3 where id=3952602;
　　+----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------+
　　| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
　　+----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------+
　　| 1 | SIMPLE | t3 | const | PRIMARY,idx_t3_id | PRIMARY | 4 | const | 1 | |
　　+----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------+

　　(3). eq_ref
　　對於每個來自於前面的表的行組合，從該表中讀取一行。這可能是最好的聯接型別，除了const型別。它用在一個索引的所有部分被聯接使用並且索引是UNIQUE或PRIMARY KEY。
　　eq_ref可以用於使用= 操作符比較的帶索引的列。比較值可以為常量或一個使用在該表前面所讀取的表的列的表示式。
　　在下面的例子中，MySQL可以使用eq_ref聯接來處理ref_tables：
程式程式碼
Select * FROM ref_table,other_table
　　Where ref_table.key_column=other_table.column;
　　Select * FROM ref_table,other_table
　　Where ref_table.key_column_part1=other_table.column
　　AND ref_table.key_column_part2=1;
　　

　　例如
程式程式碼
mysql> create unique index idx_t3_id on t3(id) ;
　　Query OK, 1000 rows affected (0.03 sec)
　　Records: 1000 Duplicates: 0 Warnings: 0
　　mysql> explain select * from t3,t4 where t3.id=t4.accountid;
　　+----+-------------+-------+--------+-------------------+-----------+---------+----------------------+------+-------+
　　| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
　　+----+-------------+-------+--------+-------------------+-----------+---------+----------------------+------+-------+
　　| 1 | SIMPLE | t4 | ALL | NULL | NULL | NULL | NULL | 1000 | |
　　| 1 | SIMPLE | t3 | eq_ref | PRIMARY,idx_t3_id | idx_t3_id | 4 | dbatest.t4.accountid | 1 | |
　　+----+-------------+-------+--------+-------------------+-----------+---------+----------------------+------+-------+

　　(4).ref
　　對於每個來自於前面的表的行組合，所有有匹配索引值的行將從這張表中讀取。如果聯接只使用鍵的最左邊的字首，或如果鍵不是UNIQUE或PRIMARY KEY(換句話說，如果聯接不能基於關鍵字選擇單個行的話)，則使用ref。如果使用的鍵僅僅匹配少量行，該聯接型別是不錯的。
　　ref可以用於使用=或<=>操作符的帶索引的列。
　　在下面的例子中，MySQL可以使用ref聯接來處理ref_tables：
程式程式碼
Select * FROM ref_table Where key_column=expr;
Select * FROM ref_table,other_table
Where ref_table.key_column=other_table.column;
Select * FROM ref_table,other_table
Where ref_table.key_column_part1=other_table.column
AND ref_table.key_column_part2=1;

　　例如:
程式程式碼
mysql> drop index idx_t3_id on t3;
　　Query OK, 1000 rows affected (0.03 sec)
　　Records: 1000 Duplicates: 0 Warnings: 0
　　mysql> create index idx_t3_id on t3(id) ;
　　Query OK, 1000 rows affected (0.04 sec)
　　Records: 1000 Duplicates: 0 Warnings: 0
　　mysql> explain select * from t3,t4 where t3.id=t4.accountid;
　　+----+-------------+-------+------+-------------------+-----------+---------+----------------------+------+-------+
　　| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
　　+----+-------------+-------+------+-------------------+-----------+---------+----------------------+------+-------+
　　| 1 | SIMPLE | t4 | ALL | NULL | NULL | NULL | NULL | 1000 | |
　　| 1 | SIMPLE | t3 | ref | PRIMARY,idx_t3_id | idx_t3_id | 4 | dbatest.t4.accountid | 1 | |
　　+----+-------------+-------+------+-------------------+-----------+---------+----------------------+------+-------+
　　2 rows in set (0.00 sec)

　　(5). ref_or_null
　　該聯接型別如同ref，但是添加了MySQL可以專門搜尋包含NULL值的行。在解決子查詢中經常使用該聯接型別的優化。
　　在下面的例子中，MySQL可以使用ref_or_null聯接來處理ref_tables：
Select * FROM ref_table
Where key_column=expr or key_column IS NULL;

　　(7). unique_subquery
　　該型別替換了下面形式的IN子查詢的ref：
value IN (Select primary_key FROM single_table Where some_expr)

　　unique_subquery是一個索引查詢函式，可以完全替換子查詢，效率更高。
　　(8).index_subquery
　　該聯接型別類似於unique_subquery。可以替換IN子查詢，但只適合下列形式的子查詢中的非唯一索引：
程式程式碼
value IN (Select key_column FROM single_table Where some_expr)

　　該聯接型別與ALL相同，除了只有索引樹被掃描。這通常比ALL快，因為索引檔案通常比資料檔案小。
　　當查詢只使用作為單索引一部分的列時，MySQL可以使用該聯接型別。
　　(11). ALL
　　對於每個來自於先前的表的行組合，進行完整的表掃描。如果表是第一個沒標記const的表，這通常不好，並且通常在它情況下很差。通常可以增加更多的索引而不要使用ALL，使得行能基於前面的表中的常數值或列值被檢索出。
　　5.possible_keys
　　possible_keys列指出MySQL能使用哪個索引在該表中找到行。注意，該列完全獨立於EXPLAIN輸出所示的表的次序。這意味著在possible_keys中的某些鍵實際上不能按生成的表次序使用。
　　如果該列是NULL，則沒有相關的索引。在這種情況下，可以通過檢查Where子句看是否它引用某些列或適合索引的列來提高你的查詢效能。如果是這樣，創造一個適當的索引並且再次用EXPLAIN檢查查詢
　　6. key
　　key列顯示MySQL實際決定使用的鍵(索引)。如果沒有選擇索引，鍵是NULL。要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
　　7.key_len
　　key_len列顯示MySQL決定使用的鍵長度。如果鍵是NULL，則長度為NULL。
　　使用的索引的長度。在不損失精確性的情況下，長度越短越好
　　8. ref
　　ref列顯示使用哪個列或常數與key一起從表中選擇行。
　　9. rows
　　rows列顯示MySQL認為它執行查詢時必須檢查的行數。
　　10. Extra
　　該列包含MySQL解決查詢的詳細資訊,下面詳細.
　　(1).Distinct
　　一旦MYSQL找到了與行相聯合匹配的行，就不再搜尋了
　　(2).Not exists
　　MYSQL優化了LEFT JOIN，一旦它找到了匹配LEFT JOIN標準的行，
　　就不再搜尋了
　　(3).Range checked for each
　　Record(index map:#)
　　沒有找到理想的索引，因此對於從前面表中來的每一個行組合，MYSQL檢查使用哪個索引，並用它來從表中返回行。這是使用索引的最慢的連線之一
　　(4).Using filesort
　　看到這個的時候，查詢就需要優化了。MYSQL需要進行額外的步驟來發現如何對返回的行排序。它根據連線型別以及儲存排序鍵值和匹配條件的全部行的行指標來排序全部行
　　(5).Using index
　　列資料是從僅僅使用了索引中的資訊而沒有讀取實際的行動的表返回的，這發生在對錶的全部的請求列都是同一個索引的部分的時候
　　(6).Using temporary
　　看到這個的時候，查詢需要優化了。這裡，MYSQL需要建立一個臨時表來儲存結果，這通常發生在對不同的列集進行ORDER BY上，而不是GROUP BY上
　　(7).Using where
　　使用了Where從句來限制哪些行將與下一張表匹配或者是返回給使用者。如果不想返回表中的全部行，並且連線型別ALL或index，這就會發生，或者是查詢有問題

二、 optimizer_trace

從MySQL5.6版本開始，optimizer_trace 可支援把MySQL查詢執行計劃樹打印出來，對DBA深入分析SQL執行計劃，COST成本都非常有用，列印的內部資訊比較全面。預設是關閉的，功能支援動態開關，因為對效能有20%左右影響，只建議分析問題時，臨時開啟。

2.演示 optimizer_trace 簡單的使用流程：
2.1 會話級別臨時開啟
mysql> set session optimizer_trace="enabled=on",end_markers_in_json=on;
2.2 執行你的SQL
select host,user,plugin from user ;
2.3 查詢information_schema.optimizer_trace表
mysql> SELECT trace FROM information_schema.OPTIMIZER_TRACE\G;
2.4 匯入到一個命名為xx.trace的檔案，然後用JSON閱讀器來檢視
SELECT TRACE INTO DUMPFILE “xx.trace” FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;

補充：永久開啟 optimizer_trace （重啟失效）
mysql> set optimizer_trace="enabled=on";

---------------------

MySQL優化之Explain命令解讀，optimizer_trace

簡述:

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

1、id的含義

2、select_type可能出現的情況（來源於Mysql5.7文件）

3、table

4、type

5、partitions

6、possible_keys

7、key

8、key_len

9、ref

10、rows

11、extra

12、filtered

MySQL優化之Explain命令解讀，optimizer_trace

MySQL查詢優化之explain的深入解析

MySQL系列-優化之explain執行計劃詳解

3萬字總結，Mysql優化之精髓

MySQL優化之——觸發器

MySQL優化之——為用戶開通mysql權限

MySQL優化之——集群搭建步驟具體解釋

mysql優化之索引

MYSQL優化-之GROUP BY

mysql 第四十七篇文章~mysql優化之相關join

Mysql優化之——啟用查詢緩存

MySQL 優化sql explain執行計劃詳解

mysql優化之key_buffer_size

mysql優化之query_cache_size

Mysql基礎之 ALTER命令

Mysql優化之高階

MySQL高階之 explain

mysql 優化之開啟慢查詢日誌並分析原因

mysql優化之sql執行流程及表結構（schema）對效能的影響

mysql優化之sql優化原則

MySQL優化之Explain命令解讀，optimizer_trace

簡述:

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

1、id的含義

2、select_type可能出現的情況（來源於Mysql5.7文件）

3、table

4、type

5、partitions

6、possible_keys

7、key

8、key_len

9、ref

10、rows

11、extra

12、filtered

相關推薦

簡述:　　