如何對SQL進行優化查詢之使用explain關鍵字進行分析？
（一）通過關鍵字explain的分析我們可以得出什麼結果？
- 表的讀取順序
- 表的讀取操作的讀取型別
- 哪些索引有可能會被使用到
- 哪些索引被實際使用了
- 表之間的引用
- 每張表有多少行被優化器查詢
（二）大體來看每個欄位都代表什麼含義？
（1）id： 可以用來看出來先執行的順序，也就是當id值越大，就越先被MySQL執行，如果id相同的話 可以認為是同一組，按照從上到下順序執行
（2）.select_type： 能夠看出來你的查詢型別，是簡單查詢、子查詢、主鍵查詢等等。所以他可能會出現六種情況
- SIMPLE：這個就表示當前就是簡單查詢
- PRIMARY：這個表示當前執行的是主鍵查詢
- SUBQUERY：這個表示當前在select或者where列表中包含了子查詢
- DERIVED：在from列表中包含的查詢被標記為DERIVED（衍生），而且MySQL會遞迴執行這些子查詢，把結果放到臨時表中
- UNION：若在第二個SELECT出現UNION之後，就被標記為 UNION； 若UNION包含在FROM子句的子查詢中，外層的select將會被標記為DERIVED
- UNION RESULT：從 UNOIN表獲取結果的result
（3） table： 就是該行所引用的表名
（4）type： 顯示了查詢使用到了那種型別，從最優的查詢到最差的排序為：system>const>eq_ref> range> index > ALL(全表掃描)
-
system：表只有一行記錄（相當於系統表），這是const型別的特例
-
const： 表示通過索引一次就找到了，const主要用於primary key 或者unique索引，因為只匹配一行資料，比如將主鍵置於where列表中，MySQL就能將該查詢轉換為一個常量。
-
eq_ref：唯一性掃描索引，對於每個索引鍵，表中只有一條記錄與之對應
-
ref： 這個表示非唯一行索引掃描，返回的是匹配某個欄位的所有行，本質上也是一中索引訪問，但是它會找到符合條件的所有行記錄
-
range： 只檢索給定範圍的行，使用一個索引來選擇行，key列顯示了使用到了那個索引 ，一般是在where語句中使用到了between、>、<和in條件查詢等。這種範圍掃描索引比全表掃描要好，因為他只需要開始於索引的某一點，結束的另一點，不需要進行全表掃描了
-
index： 雖然index 和 all 都是進行全表掃描的，但是index是通過索引查詢的資料，而 all 是直接從硬碟中進行全表掃描的
-
all： 這個就是通過從磁碟上進行全表掃描的
（5）possible_key: MySQL可能會用到那些索引在該表中找到行級記錄
（6）key： 顯示MySQL最終實際決定使用的鍵(索引)。如果沒有選擇索引,鍵是NULL
（7）key_len： 顯示MySQL決定使用的鍵長度。如果鍵是NULL,則長度為NULL。
（8）ref： 顯示索引的哪一列被使用了，如果可能的話，是一個常數，哪些列或者常量被用於查詢索引列上的值
（9）rows： 顯示MySQL認為它執行查詢時必須檢查的行數。多行之間的資料相乘可以估算要處理的行數。
（10）filtered： 顯示了通過條件過濾出的行數的百分比估計值。
（11）Extra： 就是除了以上MySQL要展示的重要的資訊之外的一個附加資訊
-
Using filesort ：（也就是無法利用索引完成的排序操作）這個表示在使用索引查詢資料的時候，MySQL使用的並不是你自己定義好的索引，而是自己又建立一個外部索引來進行查詢的（MySQL需要額外的一次傳遞，為了找出如何安排順序檢索行，一般出現這個說明查詢效能大大已經大大降低了）
-
Using temporary： 這個表示為了解決查詢,MySQL需要建立一個臨時表來容納結果，而且中間過程需要先吧資料拷貝到臨時表中，然後在刪除臨時表（這個已經嚴重到不能忍了，迫在眉睫需要優化）
-
Using index： 這個就比較美了，如果出現這個說明你建立的索引都全部被用到了，也就是索引覆蓋，可以說效率是非常的高了
-
Not exists： MySQL能夠對查詢進行LEFT JOIN優化,發現1個匹配LEFT JOIN標準的行後,不再為前面的的行組合在該表內檢查更多的行