本文將繼續上文講解其他與效率相關的引數

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等等，
顧名思義，在此不詳細累述