+----+-------------+-------+------------+------+---------------+-----+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+-----+---------+------+------+----------+-------+
使用explain關鍵字可以模擬優化器執行sql查詢語句，從而得知MySQL 是如何處理sql語句。
id
select 查詢的序列號，包含一組可以重複的數字，表示查詢中執行sql語句的順序。一般有三種情況：
第一種：id全部相同，sql的執行順序是由上至下；
第二種：id全部不同，sql的執行順序是根據id大的優先執行；
第三種：id既存在相同，又存在不同的。先根據id大的優先執行，再根據相同id從上至下的執行。
select_type
select 查詢的類型，主要是用於區別普通查詢，聯合查詢，嵌套的複雜查詢
simple：簡單的select 查詢，查詢中不包含子查詢或者union
primary：查詢中若包含任何複雜的子查詢，最外層查詢則被標記爲primary
subquery：在select或where 列表中包含了子查詢
derived：在from列表中包含的子查詢被標記爲derived（衍生）MySQL會遞歸執行這些子查詢，把結果放在臨時表裏。
union：若第二個select出現在union之後，則被標記爲union，若union包含在from子句的子查詢中，外層select將被標記爲：derived
union result：從union表獲取結果的select
partitions
表所使用的分區，如果要統計十年公司訂單的金額，可以把數據分爲十個區，每一年代表一個區。這樣可以大大的提高查詢效率。
type
這是一個非常重要的參數，連接類型，常見的有：all , index , range , ref , eq_ref , const , system , null 八個級別。性能從最優到最差的排序：system > const > eq_ref > ref > range > index > all。
對java程序員來說，若保證查詢至少達到range級別或者最好能達到ref則算是一個優秀而又負責的程序員。
all：（full table scan）全表掃描無疑是最差，若是百萬千萬級數據量，全表掃描會非常慢。
index：（full index scan）全索引文件掃描比all好很多，畢竟從索引樹中找數據，比從全表中找數據要快。
range：只檢索給定範圍的行，使用索引來匹配行。範圍縮小了，當然比全表掃描和全索引文件掃描要快。sql語句中一般會有between，in，>，< 等查詢。
ref：非唯一性索引掃描，本質上也是一種索引訪問，返回所有匹配某個單獨值的行。比如查詢公司所有屬於研發團隊的同事，匹配的結果是多個並非唯一值。
eq_ref：唯一性索引掃描，對於每個索引鍵，表中有一條記錄與之匹配。比如查詢公司的CEO，匹配的結果只可能是一條記錄，
const：表示通過索引一次就可以找到，const用於比較primary key 或者unique索引。因爲只匹配一行數據，所以很快，若將主鍵至於where列表中，MySQL就能將該查詢轉換爲一個常量。
system：表只有一條記錄（等於系統表），這是const類型的特列，平時不會出現，瞭解即可
possible_keys
顯示查詢語句可能用到的索引(一個或多個或爲null)，不一定被查詢實際使用。僅供參考使用。
key
顯示查詢語句實際使用的索引。若爲null，則表示沒有使用索引。
key_len
顯示索引中使用的字節數，可通過key_len計算查詢中使用的索引長度。在不損失精確性的情況下索引長度越短越好。key_len 顯示的值爲索引字段的最可能長度，並非實際使用長度，即key_len是根據表定義計算而得，並不是通過表內檢索出的。
ref
顯示索引的哪一列或常量被用於查找索引列上的值。
rows
根據表統計信息及索引選用情況，大致估算出找到所需的記錄所需要讀取的行數，值越大越不好。
extra
Using filesort：說明MySQL會對數據使用一個外部的索引排序，而不是按照表內的索引順序進行讀取。MySQL中無法利用索引完成的排序操作稱爲“文件排序” 。出現這個就要立刻優化sql。
Using temporary：使用了臨時表保存中間結果，MySQL在對查詢結果排序時使用臨時表。常見於排序 order by 和 分組查詢 group by。出現這個更要立刻優化sql。
Using index：表示相應的select 操作中使用了覆蓋索引（Covering index），避免訪問了表的數據行，效果不錯！如果同時出現Using where，表明索引被用來執行索引鍵值的查找。如果沒有同時出現Using where，表示索引用來讀取數據而非執行查找動作。
覆蓋索引（Covering Index） ：也叫索引覆蓋，就是select 的數據列只用從索引中就能夠取得，不必讀取數據行，MySQL可以利用索引返回select 列表中的字段，而不必根據索引再次讀取數據文件。
Using index condition：在5.6版本後加入的新特性，優化器會在索引存在的情況下，通過符合RANGE範圍的條數 和 總數的比例來選擇是使用索引還是進行全表遍歷。
Using where：表明使用了where 過濾。
Using join buffer：表明使用了連接緩存。
impossible where：where 語句的值總是false，不可用，不能用來獲取任何元素。
distinct：優化distinct操作，在找到第一匹配的元組後即停止找同樣值的動作。
filtered
一個百分比的值，和rows 列的值一起使用，可以估計出查詢執行計劃(QEP)中的前一個表的結果集，從而確定join操作的循環次數。小表驅動大表，減輕連接的次數。
通過explain的參數介紹，我們可以得知：
1. 表的讀取順序(id)
2. 數據讀取操作的操作類型(type)
3. 哪些索引被實際使用(key)
4. 表之間的引用(ref)
5. 每張表有多少行被優化器查詢(rows)
性能下降的原因
A.從程序員的角度
1. 查詢語句寫的不好
2. 沒建索引，索引建的不合理或索引失效
3. 關聯查詢有太多的join
B.從服務器的角度
1. 服務器磁盤空間不足
2. 服務器調優配置參數設置不合理
總結
1. 索引是排好序且快速查找的數據結構。其目的是爲了提高查詢的效率。
2. 創建索引後，查詢數據變快，但更新數據變慢。
3. 性能下降的原因很可能是索引失效導致。
4. 索引創建的原則，經常查詢的字段適合創建索引，頻繁需要更新的數據不適合創建索引。
5. 索引字段頻繁更新，或者表數據物理刪除容易造成索引失效。
6. 擅用 explain 分析sql語句
7. 除了優化sql語句外，還可以優化表的設計。如儘量做成單表查詢，減少表之間的關聯。設計歸檔表等。