Explain是一個非常有的命令，可以用來獲取關于查詢執行計劃的信息，以及如何解釋輸出。Explain命令是查看查詢優化器如何決定執行查詢的主要方法。這個功能有一定的局限性，并不總是會說出真相，但是它的輸出是可以獲取的最好信息，值得花時間了解，可以學習到查詢是如何執行的。
調用Explain
要使用Explain，只需在查詢中的select關鍵字之前增加Explain這個詞。MySQL會在查詢上設置一個標記。當執行查詢時，這個標記會使其返回關于在執行計劃中每一步的信息，而不是執行它。
我們來簡單看一下例子：可能是最簡單的Explain結果
在查詢中每個表在輸出中只有一行。如果查詢是兩個表的聯接，那么輸出中將有兩行。別名表單算為一個表。
Explain有兩個主要的變種
Explain extended看起來和正常的explain行為一樣，但它會告訴服務器“逆向編譯”執行計劃為一個select語句。可以通過緊接其后運行showwarnings看到這個生成的語句。這個語句直接來自執行計劃，而不是原SQL語句，到這點上已經變成一個數據結構。大部分場景下，它都是優化過的，跟原語句不相同，可以學習查詢優化器到底是如何轉化語句的。
Explain partitions會顯示查詢將訪問的分區，如果查詢是基于分區表的話。
一般認為增加explain時，MySQL語句不會執行查詢，這是錯誤的。如果查詢在from子句中包括子查詢，那么MySQL實際上是會執行子查詢，將其結果放在一個臨時表中，然后完成外層查詢優化。
前面簡單解釋了一下Explain可以做到的事情，但是Explain也有自身的一些限制：
Explain根本不會告訴你觸發器，存儲過程或者UFD會如何影響查詢。
它不支持存儲過程，盡管可以手動抽取查詢并單獨地對其進行explain操作。
它并不會告訴你MySQL在查詢執行中所做的特定優化。
它并不會顯示關于查詢的執行計劃的所有信息。
它并不區分具有相同名字的事物。比如，對內存排序和臨時文件都用“filesort”，對磁盤上和內存中的臨時表都顯示“Using temporary”。
可能會誤導。比如，會對一個有著很小的LIMIT的查詢顯示全索引掃描。
重寫非select查詢
MySQL Explain只能解釋select查詢，并不會對存儲過程調用和insert，update，delete或其他語句做解釋。但是，我們可以重寫這些非select語句來利用explain。為了利用explain，我們需要將這些語句轉化成一個等價的訪問所有相同列的select，所有需要的列必須在select列表，關聯子句，或者where子句中。
Explain中的列
0 1
id列
這一列總是包含一個編號，標示select所屬的行。數字越大越先執行，如果說數字一樣大，那么就從上往下依次執行，id列為null的就表示這是一個結果集，不需要使用它來進行查詢。
0 2
select_type列
這一列顯示了對應行是簡單還是復雜select。
常見的有：
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：與dependentunion類似，表示這個subquery的查詢要受到外部表查詢的影響
H：derived：from字句中出現的子查詢，也叫做派生表，其他數據庫中可能叫做內聯視圖或嵌套select
0 3
table列
這一列顯示了對應行正在訪問查詢的表名，如果查詢使用了別名，那么這里顯示的是別名，如果不涉及對數據表的操作，那么這顯示為null，如果顯示為尖括號括起來的<derived N>就表示這個是臨時表，后邊的N就是執行計劃中的id，表示結果來自于這個查詢產生。如果是尖括號括起來的<union M,N>，與<derived N>類似，也是一個臨時表，表示這個結果來自于union查詢的id為M,N的結果集。
0 4
type列
這一列顯示了訪問類型，即MySQL決定如何查找表中的行。
依次從好到差：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：索引范圍掃描，常見于使用>,<,isnull,between ,in ,like等運算符的查詢中。
J：index_merge：表示查詢使用了兩個以上的索引，最后取交集或者并集，常見and ，or的條件使用了不同的索引，官方排序這個在ref_or_null之后，但是實際上由于要讀取所個索引，性能可能大部分時間都不如range
K：index：索引全表掃描，把索引從頭到尾掃一遍，常見于使用索引列就可以處理不需要讀取數據文件的查詢、可以使用索引排序或者分組的查詢。
L：all：這個就是全表掃描數據文件，然后再在server層進行過濾返回符合要求的記錄。
05
possible_keys列
查詢可能使用到的索引都會在這里列出來。這個列表是優化過程早期創建的，因此有些羅列出來的索引有可能后續是沒用的。
0 6
key列
顯示了查詢真正使用到的索引，select_type為index_merge時，這里可能出現兩個以上的索引，其他的select_type這里只會出現一個。
如果該索引沒有出現在possible_keys列中，那么MySQL選用它是出于另外的原因，比如選擇了一個覆蓋索引。
possible_keys揭示了哪一個索引能有助于高效地行查找，key顯示了優化采用哪一個索引可以最小化查詢成本。
0 7
key_len列
用于處理查詢的索引長度，如果是單列索引，那就整個索引長度算進去，如果是多列索引，那么查詢不一定都能使用到所有的列，具體使用到了多少個列的索引，這里就會計算進去，沒有使用到的列，這里不會計算進去。留意下這個列的值，算一下你的多列索引總長度就知道有沒有使用到所有的列了。要注意，mysql的ICP特性使用到的索引不會計入其中。另外，key_len只計算where條件用到的索引長度，而排序和分組就算用到了索引，也不會計算到key_len中。
0 8
ref列
如果是使用的常數等值查詢，這里會顯示const，如果是連接查詢，被驅動表的執行計劃這里會顯示驅動表的關聯字段，如果是條件使用了表達式或者函數，或者條件列發生了內部隱式轉換，這里可能顯示為func
0 9
rows列
這里是執行計劃中估算的掃描行數，不是精確值
10
extra列
這個列可以顯示的信息非常多，有幾十種，常用的有
A：distinct：在select部分使用了distinc關鍵字
B：no tables used：不帶from字句的查詢或者Fromdual查詢
C：使用not in形式子查詢或notexists運算符的連接查詢，這種叫做反連接。即，一般連接查詢是先查詢內表，再查詢外表，反連接就是先查詢外表，再查詢內表。
D：using filesort：排序時無法使用到索引時，就會出現這個。常見于order by和group by語句中
E：using index：查詢時不需要回表查詢，直接通過索引就可以獲取查詢的數據。
F：using join buffer（block nestedloop），using join buffer（batched key accss）：5.6.x之后的版本優化關聯查詢的BNL，BKA特性。主要是減少內表的循環數量以及比較順序地掃描查詢。
G：using sort_union，using_union，usingintersect，using sort_intersection：
using intersect：表示使用and的各個索引的條件時，該信息表示是從處理結果獲取交集
using union：表示使用or連接各個使用索引的條件時，該信息表示從處理結果獲取并集
using sort_union和usingsort_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層過濾后，剩下多少滿足查詢的記錄數量的比例，注意是百分比，不是具體記錄數。
縱向表結構輸出
在查詢過程中，有時候信息太多的時候，橫向輸出會特別不容易讀取，這時候，我們可以使用G將結果進行格式轉換，將橫向的表結構會轉為使用縱向表結構輸出，利于閱讀。
這個格式化輸出也可以用在select語句后。
