在日常工作中，我們會有時會開慢查詢去記錄一些執行時間比較久的SQL語句，找出這些SQL語句並不意味著完事了，些時我們常常用到explain這個命令來檢視一個這些SQL語句的執行計劃，檢視該SQL語句有沒有使用上了索引，有沒有做全表掃描，這都可以通過explain命令來檢視。所以我們深入瞭解MySQL的基於開銷的優化器，還可以獲得很多可能被優化器考慮到的訪問策略的細節，以及當執行SQL語句時哪種策略預計會被優化器採用。

EXPLAIN SELECT * from t_user  where name = 'aaa';

expain出來的資訊有10列，分別是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra

概要描述：
id:選擇識別符號
select_type:表示查詢的型別。
table:輸出結果集的表
partitions:匹配的分割槽
type:表示表的連線型別
possible_keys:表示查詢時，可能使用的索引
key:表示實際使用的索引
key_len:索引欄位的長度
ref:列與索引的比較
rows:掃描出的行數(估算的行數)
filtered:按表條件過濾的行百分比
Extra:執行情況的描述和說明

下面對這些欄位出現的可能進行解釋：

一、 id
SELECT識別符。這是SELECT的查詢序列號
我的理解是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的結果，union語句中第二個select開始後面所有select)
(6) SUBQUERY(子查詢中的第一個SELECT，結果不依賴於外部查詢)
(7) DEPENDENT SUBQUERY(子查詢中的第一個SELECT，依賴於外部查詢)
(8) DERIVED(派生表的SELECT, FROM子句的子查詢)
(9) UNCACHEABLE SUBQUERY(一個子查詢的結果不能被快取，必須重新評估外連結的第一行)

三、table
顯示這一步所訪問資料庫中表名稱（顯示這一行的資料是關於哪張表的），有時不是真實的表名字，可能是簡稱，例如上面的e，d，也可能是第幾步執行的結果的簡稱

四、type
對錶訪問方式，表示MySQL在表中找到所需行的方式，又稱“訪問型別”。
常用的型別有： ALL、index、range、 ref、eq_ref、const、system、NULL（從左到右，效能從差到好）
ALL：Full Table Scan， MySQL將遍歷全表以找到匹配的行
index: Full Index Scan，index與ALL區別為index型別只遍歷索引樹
range:只檢索給定範圍的行，使用一個索引來選擇行
ref: 表示上述表的連線匹配條件，即哪些列或常量被用於查詢索引列上的值
eq_ref: 類似ref，區別就在使用的索引是唯一索引，對於每個索引鍵值，表中只有一條記錄匹配，簡單來說，就是多表連線中使用primary key或者 unique key作為關聯條件
const、system: 當MySQL對查詢某部分進行優化，並轉換為一個常量時，使用這些型別訪問。如將主鍵置於where列表中，MySQL就能將該查詢轉換為一個常量，system是const型別的特例，當查詢的表只有一行的情況下，使用system
NULL: MySQL在優化過程中分解語句，執行時甚至不用訪問表或索引，例如從一個索引列裡選取最小值可以通過單獨索引查詢完成。

五、possible_keys
指出MySQL能使用哪個索引在表中找到記錄，查詢涉及到的欄位上若存在索引，則該索引將被列出，但不一定被查詢使用（該查詢可以利用的索引，如果沒有任何索引顯示 null）
該列完全獨立於EXPLAIN輸出所示的表的次序。這意味著在possible_keys中的某些鍵實際上不能按生成的表次序使用。
如果該列是NULL，則沒有相關的索引。在這種情況下，可以通過檢查WHERE子句看是否它引用某些列或適合索引的列來提高你的查詢效能。如果是這樣，創造一個適當的索引並且再次用EXPLAIN檢查查詢

六、Key
key列顯示MySQL實際決定使用的鍵（索引），必然包含在possible_keys中
如果沒有選擇索引，鍵是NULL。要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

七、key_len
表示索引中使用的位元組數，可通過該列計算查詢中使用的索引的長度（key_len顯示的值為索引欄位的最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的）
不損失精確性的情況下，長度越短越好

八、ref
列與索引的比較，表示上述表的連線匹配條件，即哪些列或常量被用於查詢索引列上的值

九、rows
估算出結果集行數，表示MySQL根據表統計資訊及索引選用情況，估算的找到所需的記錄所需要讀取的行數

十、Extra

該列包含MySQL解決查詢的詳細資訊,下面詳細.
(1).Distinct
一旦MYSQL找到了與行相聯合匹配的行，就不再搜尋了
(2).Not exists
MYSQL優化了LEFT JOIN，一旦它找到了匹配LEFT JOIN標準的行，就不再搜尋了
(3).Range checked for each
Record（index map:#）
沒有找到理想的索引，因此對於從前面表中來的每一個行組合，MYSQL檢查使用哪個索引，並用它來從表中返回行。這是使用索引的最慢的連線之一
(4).Using filesort
看到這個的時候，查詢就需要優化了。MYSQL需要進行額外的步驟來發現如何對返回的行排序。它根據連線型別以及儲存排序鍵值和匹配條件的全部行的行指標來排序全部行
(5).Using index
列資料是從僅僅使用了索引中的資訊而沒有讀取實際的行動的表返回的，這發生在對錶的全部的請求列都是同一個索引的部分的時候
(6).Using temporary
看到這個的時候，查詢需要優化了。這裡，MYSQL需要建立一個臨時表來儲存結果，這通常發生在對不同的列集進行ORDER BY上，而不是GROUP BY上
(7).Using where
使用了WHERE從句來限制哪些行將與下一張表匹配或者是返回給使用者。如果不想返回表中的全部行，並且連線型別ALL或index，這就會發生，或者是查詢有問題

總結：
• EXPLAIN不會告訴你關於觸發器、儲存過程的資訊或使用者自定義函式對查詢的影響情況
• EXPLAIN不考慮各種Cache
• EXPLAIN不能顯示MySQL在執行查詢時所作的優化工作
• 部分統計資訊是估算的，並非精確值
• EXPALIN只能解釋SELECT操作，其他操作要重寫為SELECT後檢視執行計劃。
通過收集統計資訊不可能存在結果