MySQL EXPLAIN 詳解
Table 8.1 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 |
1.id 執行的順序 值越大越先執行 相同數值 從上而下執行
2.select type
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 除了from字句中包含的子查詢外,其他地方出現的子查詢都可能是subquery |
DEPENDENT SUBQUERY | dependent (true) | First SELECT in subquery, dependent on outer query 與dependent union類似,表示這個subquery的查詢要受到外部表查詢的影響 |
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) |
1)、id列數字越大越先執行,如果說數字一樣大,那麼就從上往下依次執行,id列為null的就表是這是一個結果集,不需要使用它來進行查詢。
2)、select_type列常見的有:
A:simple:表示不需要union操作或者不包含子查詢的簡單select查詢。有連線查詢時,外層的查詢為simple,且只有一個
B:primary:一個需要union操作或者含有子查詢的select,位於最外層的單位查詢的select_type即為primary。且只有一個
C:union:union連線的兩個select查詢,第一個查詢是dervied派生表,除了第一個表外,第二個以後的表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字句中出現的子查詢,也叫做派生表,其他資料庫中可能叫做內聯檢視或巢狀select
3)、table
顯示的查詢表名,如果查詢使用了別名,那麼這裡顯示的是別名,如果不涉及對資料表的操作,那麼這顯示為null,如果顯示為尖括號括起來的<derived N>就表示這個是臨時表,後邊的N就是執行計劃中的id,表示結果來自於這個查詢產生。如果是尖括號括起來的<union M,N>,與<derived N>類似,也是一個臨時表,表示這個結果來自於union查詢的id為M,N的結果集。
4)、type
依次從好到差:system,const,eq_ref,ref,fulltext,ref_or_null,unique_subquery,index_subquery,range,index_merge,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值的比較。實際用的不多。
G:unique_subquery:用於where中的in形式子查詢,子查詢返回不重複值唯一值
H:index_subquery:用於in形式子查詢使用到了輔助索引或者in常數列表,子查詢可能返回重複值,可以使用索引將子查詢去重。
I:range:索引範圍掃描,常見於使用>,<,is null,between ,in ,like等運算子的查詢中。
J:index_merge:表示查詢使用了兩個以上的索引,最後取交集或者並集,常見and ,or的條件使用了不同的索引,官方排序這個在ref_or_null之後,但是實際上由於要讀取所個索引,效能可能大部分時間都不如range
K:index:索引全表掃描,把索引從頭到尾掃一遍,常見於使用索引列就可以處理不需要讀取資料檔案的查詢、可以使用索引排序或者分組的查詢。
L:all:這個就是全表掃描資料檔案,然後再在server層進行過濾返回符合要求的記錄。
5)、possible_keys
查詢可能使用到的索引都會在這裡列出來
6)、key
查詢真正使用到的索引,select_type為index_merge時,這裡可能出現兩個以上的索引,其他的select_type這裡只會出現一個。
7)、key_len
用於處理查詢的索引長度,如果是單列索引,那就整個索引長度算進去,如果是多列索引,那麼查詢不一定都能使用到所有的列,具體使用到了多少個列的索引,這裡就會計算進去,沒有使用到的列,這裡不會計算進去。留意下這個列的值,算一下你的多列索引總長度就知道有沒有使用到所有的列了。要注意,mysql的ICP特性使用到的索引不會計入其中。另外,key_len只計算where條件用到的索引長度,而排序和分組就算用到了索引,也不會計算到key_len中。
8)、ref
如果是使用的常數等值查詢,這裡會顯示const,如果是連線查詢,被驅動表的執行計劃這裡會顯示驅動表的關聯欄位,如果是條件使用了表示式或者函式,或者條件列發生了內部隱式轉換,這裡可能顯示為func
9)、rows
這裡是執行計劃中估算的掃描行數,不是精確值
10)、extra
這個列可以顯示的資訊非常多,有幾十種,常用的有
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()型別的子查詢中,子查詢返回的可能有重複記錄時,就可能出現這個
除了這些之外,還有很多查詢資料字典庫,執行計劃過程中就發現不可能存在結果的一些提示資訊
11)、filtered
使用explain extended時會出現這個列,5.7之後的版本預設就有這個欄位,不需要使用explain extended了。這個欄位表示儲存引擎返回的資料在server層過濾後,剩下多少滿足查詢的記錄數量的比例,注意是百分比,不是具體記錄數。
作者:小蘿蔔
出處:小蘿蔔的部落格 http://www.cnblogs.com/xiaoboluo768/
感謝您的認真閱讀。本文版權歸作者所有,歡迎轉載,但請保留該宣告。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/26526320/viewspace-2142445/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL Explain詳解MySqlAI
- MySQL explain命令詳解MySqlAI
- 詳解 MySQL 中的 explainMySqlAI
- Mysql Explain 詳解 [原創]MySqlAI
- MySQL EXPLAIN 命令詳解學習MySqlAI
- [MySQL 優化] Explain 之 type 詳解MySql優化AI
- MySQL Explain執行計劃 - 詳解MySqlAI
- mysql explain 執行計劃詳解MySqlAI
- MySQL執行計劃EXPLAIN詳解MySqlAI
- MySQL的EXPLAIN命令結果詳解MySqlAI
- MySQL explain 中 key_len的詳解MySqlAI
- MySQL explain 和 profiling 詳解MySqlAI
- MySQL explain執行計劃詳細解釋MySqlAI
- mysql explain 命令講解MySqlAI
- MySQL EXPLAIN命令詳解學習(檢視執行計劃)MySqlAI
- Explain執行計劃詳解AI
- SQL之EXPLAIN語法詳解SQLAI
- MySQL explainMySqlAI
- [Mysql]ExplainMySqlAI
- MySQL 索引 +explainMySql索引AI
- MySQL Explain的使用MySqlAI
- MySQL的Explain結果輸出項解釋MySqlAI
- MySQL的Explain總結MySqlAI
- mysql explain的bug薦MySqlAI
- mysql explain預估剖析MySqlAI
- MySQL學習之explainMySqlAI
- MySQL 中的 EXPLAIN 命令MySqlAI
- Hive底層原理:explain執行計劃詳解HiveAI
- 【Mysql】MySQL查詢最佳化-explainMySqlAI
- MySQL優化從執行計劃開始(explain超詳細)MySql優化AI
- 卡卡西:一文詳解explain各欄位含義AI
- MySQL調優篇 | EXPLAIN執行計劃解讀(4)MySqlAI
- Mysql效能調優工具Explain結合語句講解MySqlAI
- [MySql]explain用法及實踐MySqlAI
- mysql優化之explain 指令MySql優化AI
- mysql執行計劃explainMySqlAI
- mysql explain 執行計劃MySqlAI
- MySQL版本詳解MySql