本文將繼續上文講解其他與效率相關的參數
explain所返回的其他參數key爲使用的索引,而使用的索引又影響着連接類型type,它們共同決定了可能掃描行數rows
參數解析
(4)type (重點)
聯接類型。查詢效率的關鍵,下面按照從最佳類型到最壞類型進行排序
1.system 存在於手冊中(沒怎麼見過),最好的連接類型,是const聯接類型的一個特例。
2.const 表最多有一個匹配行,它將在查詢開始時被讀取。因爲僅有一行,在這行的列值可被優化器剩餘部分認爲是常數。const表很快,因爲它們只讀取一次! 即在查詢主鍵索引或是唯一索引時使用。
select * from table where id=1 //利用主鍵查詢
3.eq_ref 在連接查詢時,連接字段使用主鍵或是唯一索引時被使用,很常見:
EXPLAIN
SELECT o.storeorder_id,o.storeorder_sn,i.stores_name
FROM `ec_stores_order` o
INNER JOIN ec_stores_info i on i.stores_id=o.store_id
可以看到sql通過stores_info表主鍵stores_id連接查詢只掃描一行記錄,是相當快速的。
4.ref 與eq_ref相對,在連接查詢時,連接字段使用非主鍵或是唯一索引的普通索引、單列索引或是組合索引的左前綴時被使用,該連接方式可以在索引列範圍查詢(< = >)時被使用。
將一sql改寫爲如下等效sql:
EXPLAIN
SELECT o.storeorder_id,o.storeorder_sn,i.stores_name
FROM ec_stores_order o
INNER JOIN (SELECT stores_id,stores_name from ec_stores_info) i on i.stores_id = o.store_id
已知stores_order表中已經建有store_id與order_status的組合索引 名IDX_STORE_ID_ORDER_STATUS,store_id爲左前綴。explain返回結果變成了:
由於連接的是子查詢的結果集,無法使用stores_info表主鍵索引。故而使用stores_order表中的索引。
5.ref_or_null
連接的索引列中有null值,ref就會變成這個。
6 index_merge
該聯接類型表示使用了索引合併優化方法。在這種情況下,key列包含了使用的索引的清單,key_len包含了使用的索引的最長的關鍵元素。
7 unique_subquery
該類型替換了IN子查詢。
unique_subquery是一個索引查找函數,可以完全替換子查詢,效率更高。只適用於主鍵或唯一索引。
EXPLAIN
SELECT o.storeorder_id,o.storeorder_sn
FROM ec_stores_order o
where o.store_id in(select stores_id from ec_stores_info where stores_creatorid=3)
8 index_subquery
該聯接類型類似於unique_subquery。可以替換IN子查詢,但只適合非唯一索引。
9 range
只檢索給定範圍的行,使用一個索引來選擇行。key列顯示使用了哪個索引。key_len包含所使用索引的最長關鍵元素。在該類型中ref列爲NULL。
當使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符,用常量比較關鍵字列時,可以使用range。
10 index
該聯接類型與ALL相同,除了只有索引樹被掃描。這通常比ALL快,因爲索引文件通常比數據文件小。
當查詢只使用作爲單索引一部分的列時,MySQL可以使用該聯接類型。(會掃描整棵索引樹)。
11 ALL
沒有用到索引,將掃描全表記錄,應極力避免。
(5)possible_keys
可能能用到的索引,沒什麼卵用~
(6)key
用到的索引名,關鍵。查詢效率與索引使用息息相關
(7)key_len
MYSQL使用的索引長度
(8)ref
顯示回行時所使用的列和參數。(回行:即通過索引檢索到記錄標識後,返回數據庫查找所在行的詳細數據。有空的話,我會寫一篇索引工作原理在其中詳細介紹)
(9)rows
顯示查詢掃描的行數,顯然數值越大越不好。這只是預估值。
(9)Extra
查詢的詳細信息,包含所有其他操作,例如
Distinct,using index,using where,Using union等等,
顧名思義,在此不詳細累述