在日常工作中，我們會有時會開慢查詢去記錄一些執行時間比較久的SQL語句，找出這些SQL語句並不意味着完事了，些時我們常常用到explain 這個命令來查看一個這些SQL語句的執行計劃，查看該SQL語句有沒有使用上了索引，有沒有做全表掃描，這都可以通過explain命令來查看。所以我們 深入瞭解MySQL的基於開銷的優化器，還可以獲得很多可能被優化器考慮到的訪問策略的細節，以及當運行SQL語句時哪種策略預計會被優化器採用。 （QEP：sql生成一個執行計劃query Execution plan）
- table：顯示這一行的數據是關於哪張表的
- type：這是重要的列，顯示連接使用了何種類型。從最好到最差的連接類型爲const、eq_reg、ref、range、index和ALL
- type顯示的是訪問類型，是較爲重要的一個指標，結果值從好到壞依次是：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
一般來說，得保證查詢至少達到range級別，最好能達到ref。- possible_keys：顯示可能應用在這張表中的索引。如果爲空，沒有可能的索引。可以爲相關的域從WHERE語句中選擇一個合適的語句
- key： 實際使用的索引。如果爲NULL，則沒有使用索引。很少的情況下，MYSQL會選擇優化不足的索引。這種情況下，可以在SELECT語句中使用USE INDEX（indexname）來強制使用一個索引或者用IGNORE INDEX（indexname）來強制MYSQL忽略索引
- key_len：使用的索引的長度。在不損失精確性的情況下，長度越短越好
- ref：顯示索引的哪一列被使用了，如果可能的話，是一個常數
- rows：MYSQL認爲必須檢查的用來返回請求數據的行數
- Extra：關於MYSQL如何解析查詢的額外信息。將在表4.3中討論，但這裏可以看到的壞的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，結果是檢索會很慢
一、 id
我的理解是SQL執行的順序的標識,SQL從大到小的執行
1. id相同時，執行順序由上至下
2. 如果是子查詢，id的序號會遞增，id值越大優先級越高，越先被執行
3.id如果相同，可以認爲是一組，從上往下順序執行；在所有組中，id值越大，優先級越高，越先執行
二、select_type
示查詢中每個select子句的類型
(1) SIMPLE(簡單SELECT,不使用UNION或子查詢等)
(2) PRIMARY(查詢中若包含任何複雜的子部分,最外層的select被標記爲PRIMARY)
(3) UNION(UNION中的第二個或後面的SELECT語句)
(4) DEPENDENT UNION(UNION中的第二個或後面的SELECT語句，取決於外面的查詢)
(5) UNION RESULT(UNION的結果)
(6) SUBQUERY(子查詢中的第一個SELECT)
(7) DEPENDENT SUBQUERY(子查詢中的第一個SELECT，取決於外面的查詢)
(8) DERIVED(派生表的SELECT, FROM子句的子查詢)
(9) UNCACHEABLE SUBQUERY(一個子查詢的結果不能被緩存，必須重新評估外鏈接的第一行)
如下:
三、table
有可能是
實際的表名 如select * from t1;
表的別名 如 select * from t2 as tmp;
derived 如from型子查詢時(來自於子查詢的派生表)
null 直接計算得結果,不用走表，例如select 1+2
顯示這一行的數據是關於哪張表的，有時不是真實的表名字,看到的是derivedx(x是個數字,我的理解是第幾步執行的結果)
mysql> explain select * from (select * from ( select * from t1 where id=2602) a) b;
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
| 1 | PRIMARY | <derived2> | system | NULL | NULL | NULL | NULL | 1 | |
| 2 | DERIVED | <derived3> | system | NULL | NULL | NULL | NULL | 1 | |
| 3 | DERIVED | t1 | const | PRIMARY,idx_t1_id | PRIMARY | 4 | | 1 | |
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
四、type(重要)
表示MySQL在表中找到所需行的方式，又稱“訪問類型”。是分析”查數據過程”的重要依據
常用的類型有： ALL, index, range, ref, eq_ref, const, system, NULL（從左到右，性能從差到好）
ALL：Full Table Scan， MySQL將遍歷全表以找到匹配的行 ,逐行做全表掃描.,運氣不好掃描到最後一行. (說明語句寫的很失敗)
index: Full Index Scan，index與ALL區別爲index類型只遍歷索引樹,相當於data_all index 掃描所有的索引節點,相當於index_all
range:只檢索給定範圍的行，使用一個索引來選擇行,能根據索引做範圍的掃描
ref: 表示上述表的連接匹配條件，即哪些列或常量被用於查找索引列上的值,通過索引列,可以直接引用到某些數據行
eq_ref: 類似ref，區別就在使用的索引是唯一索引，對於每個索引鍵值，表中只有一條記錄匹配，簡單來說，就是多表連接中使用primary key或者 unique key作爲關聯條件
const、system: 當MySQL對查詢某部分進行優化，並轉換爲一個常量時，使用這些類型訪問。如將主鍵置於where列表中，MySQL就能將該查詢轉換爲一個常量,system是const類型的特例，當查詢的表只有一行的情況下，使用system
NULL: MySQL在優化過程中分解語句，執行時甚至不用訪問表或索引，例如從一個索引列裏選取最小值可以通過單獨索引查找完成。
const、system、NULL指查詢優化到常量級別, 甚至不需要查找時間.
五、possible_keys
注意: 系統估計可能用的幾個索引,但最終,只能用1個.
指出MySQL能使用哪個索引在表中找到記錄，查詢涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢使用
該列完全獨立於EXPLAIN輸出所示的表的次序。這意味着在possible_keys中的某些鍵實際上不能按生成的表次序使用。
如果該列是NULL，則沒有相關的索引。在這種情況下，可以通過檢查WHERE子句看是否它引用某些列或適合索引的列來提高你的查詢性能。如果是這樣，創造一個適當的索引並且再次用EXPLAIN檢查查詢
六、Key
key列顯示MySQL實際決定使用的鍵（索引）
如果沒有選擇索引，鍵是NULL。要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
七、key_len
表示索引中使用的字節數，可通過該列計算查詢中使用的索引的長度（key_len顯示的值爲索引字段的最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的）
不損失精確性的情況下，長度越短越好
八、ref
表示上述表的連接匹配條件，即哪些列或常量被用於查找索引列上的值
九、rows
表示MySQL根據表統計信息及索引選用情況，估算的找到所需的記錄所需要讀取的行數
有時候結果集中多一列filtered
爲什麼Mysql explain extended中的filtered列值總是100%
執行Mysql的explain extended的輸出會比單純的explain多一列filtered(MySQL 5.7缺省就會輸出filtered)，它指返回結果的行佔需要讀到的行(rows列的值)的百分比。按說filtered是個非常有用的值，因爲對於join操作，前一個表的結果集大小直接影響了循環的次數。但是我的環境下測試的結果卻是，filtered的值一直是100%，也就是說失去了意義。
參考下面mysql 5.6的代碼，filtered值只對index和all的掃描有效（這可以理解，其它場合，通常rows值就等於估算的結果集大小。）。
十、Extra
性能從好到壞:useing index>usinh where > using temporary | using filesort
該列包含MySQL解決查詢的詳細信息,有以下幾種情況：
Using temporary：表示MySQL需要使用臨時表來存儲結果集，常見於排序和分組查詢
Using filesort：MySQL中無法利用索引完成的排序操作稱爲“文件排序”
Using where:列數據是從僅僅使用了索引中的信息而沒有讀取實際的行動的表返回的，這發生在對錶的全部的請求列都是同一個索引的部分的時候，表示mysql服務器將在存儲引擎檢索行後再進行過濾
Using join buffer：改值強調了在獲取連接條件時沒有使用索引，並且需要連接緩衝區來存儲中間結果。如果出現了這個值，那應該注意，根據查詢的具體情況可能需要添加索引來改進能。
Impossible where：這個值強調了where語句會導致沒有符合條件的行。
Select tables optimized away：這個值意味着僅通過使用索引，優化器可能僅從聚合函數結果中返回一行
useing index代表索引覆蓋，就是查詢的列正好在索引中，不用回物理行查詢數據。參考http://www.cnblogs.com/qlqwjy/p/8593076.html
總結：
• EXPLAIN不會告訴你關於觸發器、存儲過程的信息或用戶自定義函數對查詢的影響情況
• EXPLAIN不考慮各種Cache
• EXPLAIN不能顯示MySQL在執行查詢時所作的優化工作
• 部分統計信息是估算的，並非精確值
• EXPALIN只能解釋SELECT操作，其他操作要重寫爲SELECT後查看執行計劃