Explain舉例mysql>?explain?select?*?from?event;

+—-+————-+——-+——+—————+——+———+——+——+——-+

|?id?|?select_type?|?table?|?type?|?possible_keys?|?key?|?key_len?|?ref?|?rows?|?Extra?|

+—-+————-+——-+——+—————+——+———+——+——+——-+

|?1?|?SIMPLE?|?event?|?ALL?|?NULL?|?NULL?|?NULL?|?NULL?|?13?|?|

+—-+————-+——-+——+—————+——+———+——+——+——-+

1?row?in?set?(0.00?sec)

各個屬性的含義

id

Query Optimizer 所選定的執行計劃中查詢的序列號

select_type

select查詢的類型，主要是區別普通查詢和聯合查詢、子查詢之類的復雜查詢。

各項內容含義說明：

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

輸出的行所引用的表。

type

聯合查詢所使用的類型。

type顯示的是訪問類型，是較為重要的一個指標，結果值從好到壞依次是：

system

> const > eq_ref > ref > fulltext > ref_or_null >

index_merge > unique_subquery > index_subquery > range >

index > ALL

一般來說，得保證查詢至少達到range級別，最好能達到ref。除了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：索引范圍掃描，常見于使用 =, <>, >, >=, , BETWEEN, IN()或者like等運算符的查詢中。

K：index：索引全表掃描，把索引從頭到尾掃一遍，常見于使用索引列就可以處理不需要讀取數據文件的查詢、可以使用索引排序或者分組的查詢。

possible_keys

指出MySQL能使用哪個索引在該表中找到行。

key

顯示MySQL實際決定使用的鍵。如果沒有索引被選擇，鍵是NULL。

key_len

顯示MySQL決定使用的鍵長度。如果鍵是NULL，長度就是NULL。文檔提示特別注意這個值可以得出一個多重主鍵里mysql實際使用了哪一部分。

ref

顯示哪個字段或常數與key一起被使用。

rows

這個數表示mysql要遍歷多少數據才能找到，在innodb上是不準確的。

Extra

如果你想要優化你的查詢，那就要注意extra輔助信息中的using filesort和using temporary，這兩項非常消耗性能，需要注意。

這個列可以顯示的信息非常多，有幾十種，常用的有：

distinct：在select部分使用了distinc關鍵字，當 mysql 找到了第一條匹配的結果后，將停止該值的查詢而轉為后面其他值的查詢

no tables used：不帶from字句的查詢或者From dual查詢。

使用not in()形式子查詢或not exists運算符的連接查詢，這種叫做反連接。即，一般連接查詢是先查詢內表，再查詢外表，反連接就是先查詢外表，再查詢內表。

using filesort：排序時無法使用到索引時，就會出現這個。常見于order by和group by語句中。

using index：查詢時不需要回表查詢，直接通過索引就可以獲取查詢的數據,使用覆蓋索引的時候就會出現

using

index condition: 在MySQL 5.6版本后加入的新特性ICP(Index Condition Pushdown);會先條件過濾索引，過濾完索引后找到所有符合索引條件的數據行，隨后用 WHERE 子句中的其他條件去過濾這些數據行。

using where：表示MySQL服務器在存儲引擎收到記錄后進行“后過濾”(Post-filter),如果查詢未能使用索引，Using where的作用只是提醒我們MySQL將用where子句來過濾結果集。這個一般發生在MySQL服務器，而不是存儲引擎層。一般發生在不能走索引掃描的情況下或者走索引掃描，但是有些查詢條件不在索引當中的情況下。

using join buffer(block nested loop)，using join buffer(batched key accss)：5.6.x之后的版本優化關聯查詢的BNL，BKA特性。主要是減少內表的循環數量以及比較順序地掃描查詢。

using sort_union，using_union，using intersect，using sort_intersection：

using intersect：表示使用and的各個索引的條件時，該信息表示是從處理結果獲取交集。

using union：表示使用or連接各個使用索引的條件時，該信息表示從處理結果獲取并集。

using sort_union和using sort_intersection：與前面兩個對應的類似，只是他們是出現在用and和or查詢信息量大時，先查詢主鍵，然后進行排序合并后，才能讀取記錄并返回。

using temporary：表示使用了臨時表存儲中間結果。臨時表可以是內存臨時表和磁盤臨時表，執行計劃中看不出來，需要查看status變量，used_tmp_table，used_tmp_disk_table才能看出來。

firstmatch(tb_name)：5.6.x開始引入的優化子查詢的新特性之一，常見于where字句含有in()類型的子查詢。如果內表的數據量比較大，就可能出現這個

loosescan(m..n)：5.6.x之后引入的優化子查詢的新特性之一，在in()類型的子查詢中，子查詢返回的可能有重復記錄時，就可能出現這個。

版權聲明：本文由PHP面試資料網發布，如需轉載請注明出處。

總結

以上是生活随笔為你收集整理的php explain type等级,mysql中explain分析sql详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。