前言
什么是執行計划？簡而言之，就是 SQL 在數據庫中執行時的表現情況，通常用於 SQL 性能分析、優化和加鎖分析等場景，執行過程會在 MySQL 查詢過程中由解析器，預處理器和查詢優化器共同生成。在MySQL中使用 explain 關鍵字來查看。
執行計划能告訴我們什么？她可以用來分析SQL語句和表結構的性能瓶頸。通過分析explain的輸出結果集，可以了解到諸如關聯查詢的執行順序、查詢操作的操作類型、哪些索引可以被命中、哪些索引實際被命中、每張表有多少記錄參與查詢等信息。接下來，我們將介紹在explain結果集中每一列的意義。
EXPLAIN 中的列
mysql> explain select * from servers;
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
| 1 | SIMPLE | servers | ALL | NULL | NULL | NULL | NULL | 1 | NULL |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
1 row in set (0.03 sec)
expain執行后輸出的結果集包含10列，分別是id、select_type、table、type、possible_keys、key、key_len、ref、rows和Extra，下面對這些字段進行解釋。
| 列名 | 說明 |
|---|---|
| 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 和select_type
每個被獨立執行的操作的標識，表示各個SQL片段被操作的順序；在嵌套查詢中id越大的語句越先執行，如果相同，那么按照從上到下的順序執行。該值可能為NULL，如果這一行用來說明的是其他行的聯合結果。
-- 查看在研發部並且名字以Jef開頭的員工，經典查詢
explain select e.no, e.name from emp e left join dept d on e.dept_no = d.no where e.name like 'Jef%' and d.name = '研發部';
select_type表示查詢的類型，其枚舉值和說明見下表：
| 類型 | 說明 |
|---|---|
| simple | 簡單SELECT，不包含子查詢和union |
| primary | 包含union或者子查詢，最外層的部分標記為primary |
| subquery | 一般子查詢中的子查詢被標記為subquery，也就是位於select列表中的查詢 |
| derived | 派生表——該臨時表是從子查詢派生出來的，位於from中的子查詢 |
| union | 位於union中第二個或者其以后的子查詢被標記為union，第一個就被標記為primary。若union位於from中，則標記為derived。取決於外面的查詢 |
| union result | 用來從匿名臨時表里檢索結果的select子句被標記為union result |
| dependent union | 顧名思義，首先需要滿足UNION的條件，及UNION中第二個以及后面的SELECT語句，同時該語句依賴外部的查詢 |
| subquery | 子查詢中第一個SELECT語句 |
| dependent subquery | 子查詢中的第一個 select，取決於外側的查詢，一般是 in 中的子查詢。 |
該示例中，in子查詢的select_type被標記為dependent subquery ，主查詢被標記為primary。
此圖展示了 union 和 union result 的 SQL 案例。
table
對應行正在訪問哪一個表，可以是表名或者別名
- 關聯優化器會為查詢選擇關聯順序，左側深度優先
- 當from中有子查詢的時候，表名是derivedN的形式，N指向子查詢，也就是explain結果中的下一列
- 當有union result的時候，表名是union 1,2等的形式，1,2表示參與union的query id
注意：MySQL對待這些表和普通表一樣，但是這些“臨時表”是沒有任何索引的。
type
type顯示的是各個表之間的關聯類型，表示MySQL決定如何查找表中的記錄。是最重要的一個指標，其性能從高到低依次是：
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 類型外最好的連接類型 |
| const | 當通過索引檢索最多只會有一行匹配的時候，MySQL優化器會在查詢前讀取它而且只讀取一次，因此非常快。當主鍵放入where子句時，mysql把這個查詢轉為一個常量（高效） |
| system | 這是const連接類型的一種特例，表中僅有一行數據，相當於系統表。 |
| Null | 意味說mysql能在優化階段分解查詢語句，在執行階段甚至用不到訪問表或索引（高效） |
子查詢通過id返回一條數據，故其type為const。而子查詢結果集只有一條數據（rows=1），故主查詢的type為system。
possible_keys
顯示查詢可以使用哪些索引，基於查詢訪問的列和使用的比較操作符來判斷。表示他們可以進行高效地查找，但是他們對於后續優化過程可能是沒有用的
key 和 key_len
key列顯示MySQL實際決定使用的鍵（索引）。如果沒有選擇索引，鍵是NULL。要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
key_len列顯示MySQL在索引里使用的字節數。如果鍵是NULL，則長度為NULL。在語義清晰時，長度越短越好 。
ref 和 rows
ref列顯示使用哪個列或常數從表中選擇行。如下圖所示，從 t2 讀取數據時，要判斷 t2.id = t1.id，所以 ref 就是 mysql.t1.id。
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操作，在找到第一匹配的元組后即停止搜索更多的行 |
| No tables used | select 語句中使用from dual 或不含任何from子句 |
如此圖所示，展示了使用連接緩存和臨時表時的Extra信息。
No tables used 示例，執行 explain select now() 也會得到相同的結果。
小結
- EXPLAIN不會告訴你關於觸發器、存儲過程的信息或用戶自定義函數對查詢的影響情況
- EXPLAIN不考慮各種Cache
- EXPLAIN不能顯示MySQL在執行查詢時所作的優化工作
- 部分統計信息是估算的，並非精確值
- EXPALIN只能解釋SELECT操作，其他操作要重寫為SELECT后查看執行計划。
以上就是這篇文章的全部內容了，希望本文對大家的學習或者工作具有一定的參考和學習價值；如果有疑問，大家可以在評論區留言交流，也希望大家多多點贊關注。謝謝大家對樓蘭的胡楊的支持！