MySQL_執行計劃詳細說明

 

 

 

1 簡要說明

id	表格查詢的順序編號。	降序查看，id相同的從上到下查查看。 id能夠爲null ，當table爲( union ,m,n )類型的時候，id爲null，這個時候，id的順序爲 m跟n的後面。
select_type	查詢的方式	下文詳細說明。
table	表格名稱	表名，別名，( union m,n ）。
partitions	分區名稱	查詢使用到表分區的分區名。
type	錶鏈接的類型	下文詳細說明。
possible_keys	可能使用到的索引	這裏的索引只是可能會有到，實際不必定會用到。
key	使用到的索引	實際使用的索引。
key_len	使用到索引的長度	好比多列索引，只用到最左的一列，那麼使用到索引的長度則爲該列的長度，故該值不必定等於 key 列索引的長度。
ref	謂詞的關聯信息	當 join type 爲 const、eq_ref 或者 ref 時，謂詞的關聯信息。 可能爲 ：null（非 const \ eq_ref \ ref join type 時）、const（常量）、關聯的謂詞列名。
rows	掃描的行數	該表格掃描到的行數。這裏注意在mysql裏邊是嵌套連接，因此，須要把全部rows相乘就會獲得查詢數據行關聯的次數
filtered	實際顯示行數佔掃描rows的比例	實際顯示的行數 = rows * filtered / 100
extra	特性使用

2 SELECT_TYPE

1. SIMPLE，簡單查詢方式，不使用UNION跟子查詢；
2. PRIMARY，該表格位於最外層開始查詢，一般會跟其餘查詢方式組合；
3. UNION，UNION 第一個SELECT 爲PRIMARY，第二個及以後的全部SELECT 爲 UNION SELECT TYPE；
4. UNION RESULT，每一個結果集的取出來後，會作合併操做，這個操做就是 UNION RESULT；
5. DEPENDENT UNION，子查詢中的UNION操做，從UNION 第二個及以後的全部SELECT語句的SELECT TYPE爲 DEPENDENT UNION，這個通常跟DEPENDENT SUBQUERY一塊兒結合應用，子查詢中UNION 的第一個爲DEPENDENT SUBQUERY；
6. DEPENDENT SUBQUERY，子查詢中內層的第一個SELECT，依賴於外部查詢的結果集；
7. SUBQUERY，子查詢內層查詢的第一個SELECT，結果不依賴於外部查詢結果集（不會被數據庫引擎改寫的狀況）；
8. DERIVED，查詢使用內聯視圖；
9. MATERIALIZED，子查詢物化，表出如今非相關子查詢中 而且須要進行物化時會出現MATERIALIZED關鍵詞；
10. UNCACHEABLE SUBQUERY，結果集沒法緩存的子查詢，須要逐次查詢；
11. UNCACHEABLE UNION，表示子查詢不可被物化 須要逐次運行。

2 TYPE

      性能排序：null->system->const->eq-ref->ref->fulltext->ref_or_null->index_merge->unique_subquery->index_subquery->range->index->ALL

1. null，不訪問任何一個表格
2. system
   • 官網解釋：The table has only one row (= system table). This is a special case of the const join type.
   • join type 爲const，而且表格僅含有1行記錄。
3. const
   • 主鍵或者惟一索引的常量查詢，表格最多隻有1行記錄符合查詢，一般const使用到主鍵或者惟一索引進行定值查詢。
   • 常量查詢很是快。
4. eq_ref
   • join 查詢過程當中，關聯條件爲主鍵或者惟一索引，出來的行數不止一行
   • eq_ref是一種性能很是好的 join 操做。
   • 例子說明：首先從su表格查詢全部數據共7行出來，而後每一行跟 xin 的主鍵id中的1行作匹配。
5. ref
   • 非彙集索引的常量查詢
   • 性能也是很不錯的。
6. fulltext
   • 查詢的過程當中，使用到了 fulltext 索引（fulltext index在innodb引擎中，只有5.6版本以後的支持）
   • 例子是innodb引擎下、帶fulltext index的表格查詢
7. ref_or_null
   • 跟ref查詢相似，在ref的查詢基礎上，不過會加多一個null值的條件查詢
8. index merg
   • 當條件謂詞使用到多個索引的最左邊列而且謂詞之間的鏈接爲or的狀況下，會使用到 索引聯合查詢
9. unique subquery
   • eq_ref的一個分支，查詢主鍵的子查詢：
   • value IN (SELECT primary_key FROM single_table WHERE some_expr)
   • 暫時沒法模擬出來，目前在5.7.17版本怎麼測試，出來的type都是 eq_ref
10. index subquery
    • ref的一個分支，查詢非彙集索引的子查詢：
    • value IN (SELECT key_column FROM single_table WHERE some_expr)
    • 暫時沒法模擬出來，目前在5.7.17版本怎麼測試，出來的type都是 ref
11. range
    • 當謂詞使用到索引範圍查詢的時候：=、<>、>、>=、<、<=、IS NULL、BETWEEN、IN、<=> (這是個表達式：左邊能夠推出右邊,右邊也可推出左邊)
12. index
    • 使用到索引，可是不是索引查找，而是對索引樹作一個掃描，即便是索引掃描，大多數狀況下也是比全表掃描性能要好的，由於索引樹上的鍵值只有索引列鍵值+主鍵，而全表掃描則是在 彙集索引樹（主鍵+全部列）上進行掃描，索引樹相比之下要廋得多跟小得多了。
13. all
    • 全表掃描，性能比較差。
    • 關於 index跟all，這裏再舉一個例子說明下
      • 下圖中，表格su有3個索引：主鍵、ix_age、ix_name，這三個索引樹的內容分別爲：主鍵id+全部列、age+主鍵id、name+主鍵id，依次，當掃描主鍵id查詢的時候，這三個索引都可以提供 主鍵id列，那麼哪一個性能比較好呢？索引樹最小的，掃描次數最少的則爲最優，根據索引數內容可得大小：ix_age < ix_name < pk，故執行計劃會選擇 ix_age。

3 ref

      當 join type 爲 eq_ref 或者 ref 時，謂詞的關聯信息。可能爲 ：null（非 eq_ref\ref join type時）、const（常量）、關聯的謂詞列名。

 

 

4 extra    

• 經常使用到
1. Using index，使用到索引
2. Using index conditio，使用到索引過濾
3. Using MRR，使用到索引內部排序
4. Using where，使用到where條件
5. Using temporary，使用到臨時表

1. Using index
   • 索引覆蓋，也就是不止要使用到索引，並且沒有回表查詢
   • 舉個例子說明
   • 這兩個查詢中，條件都是同樣，可是第一個返回的是全部列，而索引 IX_age上僅包含主鍵列跟索引鍵值，故須要再根據主鍵的值去PK樹上找到對應的列，這個操做稱爲回表，因此第一個查詢中extra沒有USING INDEX，而第二個查詢有。
2. Using index conditio，簡稱 ICP
3. Using MRR，簡稱 MRR
4. Using where
   • 根據where條件，先取出數據，再跟其餘表格關聯查詢
5. Using filesort，沒法利用索引來完成的排序
6. Using temporary，使用到臨時表
7. 使用到臨時表，表數量較少的狀況下，臨時表使用緩存，可是比較大的時候，則會磁盤存儲，這種狀況下，性能將會急劇降低