前言:
MySQL EXPLAIN命令是查詢性能優化不可缺少的一部分,該文主要講解explain命令的使用及相關參數說明。
EXPLAIN Output Columns:
列名 | 說明 |
---|---|
id | 執行編號,標識select所屬的行。如果在語句中沒子查詢或關聯查詢,只有唯一的select,每行都將顯示1。否則,內層的select語句一般會順序編號,對應於其在原始語句中的位置 |
select_type | 顯示本行是簡單或複雜select。如果查詢有任何複雜的子查詢,則最外層標記爲PRIMARY(DERIVED、UNION、UNION RESUlT) |
table | 訪問引用哪個表(引用某個查詢,如“derived3”) |
type | 數據訪問/讀取操作類型(ALL、index、range、ref、eq_ref、const/system、NULL) |
possible_keys | 揭示哪一些索引可能有利於高效的查找 |
key | 顯示mysql決定採用哪個索引來優化查詢 |
key_len | 顯示mysql在索引裏使用的字節數 |
ref | 顯示了之前的表在key列記錄的索引中查找值所用的列或常量 |
rows | 爲了找到所需的行而需要讀取的行數,估算值,不精確。通過把所有rows列值相乘,可粗略估算整個查詢會檢查的行數 |
Extra | 額外信息,如using index、filesort等 |
id:
id是用來順序標識整個查詢中SELELCT 語句的,在嵌套查詢中id越大的語句越先執行。該值可能爲NULL,如果這一行用來說明的是其他行的聯合結果。
select_type:
表示查詢的類型
類型 | 說明 |
---|---|
simple | 簡單子查詢,不包含子查詢和union |
primary | 包含union或者子查詢,最外層的部分標記爲primary |
subquery | 一般子查詢中的子查詢被標記爲subquery,也就是位於select列表中的查詢 |
derived | 派生表——該臨時表是從子查詢派生出來的,位於form中的子查詢 |
union | 位於union中第二個及其以後的子查詢被標記爲union,第一個就被標記爲primary如果是union位於from中則標記爲derived |
union result | 用來從匿名臨時表裏檢索結果的select被標記爲union result |
dependent union | 顧名思義,首先需要滿足UNION的條件,及UNION中第二個以及後面的SELECT語句,同時該語句依賴外部的查詢 |
subquery | 子查詢中第一個SELECT語句 |
dependent subquery | 和DEPENDENT UNION相對UNION一樣 |
table:
對應行正在訪問哪一個表,表名或者別名
- 關聯優化器會爲查詢選擇關聯順序,左側深度優先
- 當from中有子查詢的時候,表名是derivedN的形式,N指向子查詢,也就是explain結果中的下一列
- 當有union result的時候,表名是union 1,2等的形式,1,2表示參與union的query id
注意:MySQL對待這些表和普通表一樣,但是這些“臨時表”是沒有任何索引的。
type:
type顯示的是訪問類型,是較爲重要的一個指標,結果值從好到壞依次是:
system > const > eq_ref > ref > 【fulltext > ref_or_null > index_merge > unique_subquery > index_subquery】 > range > index > ALL ,一般來說,得保證查詢至少達到range級別,最好能達到ref
類型 | 說明 |
---|---|
All | 最壞的情況,全表掃描 |
index | 和全表掃描一樣。只是掃描表的時候按照索引次序進行而不是行。主要優點就是避免了排序, 但是開銷仍然非常大。如在Extra列看到Using index,說明正在使用覆蓋索引,只掃描索引的數據,它比按索引次序全表掃描的開銷要小很多 |
range | 範圍掃描,一個有限制的索引掃描。key 列顯示使用了哪個索引。當使用=、 <>、>、>=、<、<=、IS NULL、<=>、BETWEEN 或者 IN 操作符,用常量比較關鍵字列時,可以使用 range |
ref | 一種索引訪問,它返回所有匹配某個單個值的行。此類索引訪問只有當使用非唯一性索引或唯一性索引非唯一性前綴時纔會發生。這個類型跟eq_ref不同的是,它用在關聯操作只使用了索引的最左前綴,或者索引不是UNIQUE和PRIMARY KEY。ref可以用於使用=或<=>操作符的帶索引的列。 |
eq_ref | 最多隻返回一條符合條件的記錄。使用唯一性索引或主鍵查找時會發生 (高效) |
const | 當確定最多隻會有一行匹配的時候,MySQL優化器會在查詢前讀取它而且只讀取一次,因此非常快。當主鍵放入where子句時,mysql把這個查詢轉爲一個常量(高效) |
system | 這是const連接類型的一種特例,表僅有一行滿足條件。 |
Null | 意味說mysql能在優化階段分解查詢語句,在執行階段甚至用不到訪問表或索引(高效) |
possible_keys:
顯示查詢使用了哪些索引,表示該索引可以進行高效地查找,但是列出來的索引對於後續優化過程可能是沒有用的
key:
key列顯示MySQL實際決定使用的鍵(索引)。如果沒有選擇索引,鍵是NULL。要想強制MySQL使用或忽視possible_keys列中的索引,在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
key_len:
key_len列顯示MySQL決定使用的鍵長度。如果鍵是NULL,則長度爲NULL。使用的索引的長度。在不損失精確性的情況下,長度越短越好 。
ref:
ref列顯示使用哪個列或常數與key一起從表中選擇行。
rows:
rows列顯示MySQL認爲它執行查詢時必須檢查的行數。注意這是一個預估值。
Extra:
Extra是EXPLAIN輸出中另外一個很重要的列,該列顯示MySQL在查詢過程中的一些詳細信息,MySQL查詢優化器執行查詢的過程中對查詢計劃的重要補充信息。
類型 | 說明 |
---|---|
Using filesort | MySQL有兩種方式可以生成有序的結果,通過使用索引或者排序操作,當Extra中出現了Using filesort 說明MySQL使用了後者,但注意雖然叫filesort但並不是說明就是用了文件來進行排序,只要可能排序都是在內存裏完成的。大部分情況下利用索引排序更快,所以一般這時也要考慮優化查詢了。使用文件完成排序操作,這是可能是ordery by,group by語句的結果,這可能是一個CPU密集型的過程,可以通過選擇合適的索引來改進性能,用索引來爲查詢結果排序。 |
Using temporary | 用臨時表保存中間結果,常用於GROUP BY 和 ORDER BY操作中,一般看到它說明查詢需要優化了,就算避免不了臨時表的使用也要儘量避免硬盤臨時表的使用。 |
Not exists | MYSQL優化了LEFT JOIN,一旦它找到了匹配LEFT JOIN標準的行, 就不再搜索了。 |
Using index | 說明查詢是覆蓋了索引的,不需要讀取數據文件,從索引樹(索引文件)中即可獲得信息。如果同時出現using where,表明索引被用來執行索引鍵值的查找,沒有using where,表明索引用來讀取數據而非執行查找動作。這是MySQL服務層完成的,但無需再回表查詢記錄。 |
Using index condition | 這是MySQL 5.6出來的新特性,叫做“索引條件推送”。簡單說一點就是MySQL原來在索引上是不能執行如like這樣的操作的,但是現在可以了,這樣減少了不必要的IO操作,但是隻能用在二級索引上。 |
Using where | 使用了WHERE從句來限制哪些行將與下一張表匹配或者是返回給用戶。注意:Extra列出現Using where表示MySQL服務器將存儲引擎返回服務層以後再應用WHERE條件過濾。 |
Using join buffer | 使用了連接緩存:Block Nested Loop,連接算法是塊嵌套循環連接;Batched Key Access,連接算法是批量索引連接 |
impossible where | where子句的值總是false,不能用來獲取任何元組 |
select tables optimized away | 在沒有GROUP BY子句的情況下,基於索引優化MIN/MAX操作,或者對於MyISAM存儲引擎優化COUNT(*)操作,不必等到執行階段再進行計算,查詢執行計劃生成的階段即完成優化。 |
distinct | 優化distinct操作,在找到第一匹配的元組後即停止找同樣值的動作 |