explain關鍵字結果

列名所代表的的含義:

Id:MySQL QueryOptimizer 選定的執行計劃中查詢的序列號。表示查詢中執行 select 子句或操作表的順序,id 值越大優先級越高,越先被執行。id 相同,執行順序由上至下。

Select_type一共有9中類型,只介紹常用的4種:

SIMPLE: 簡單的 select 查詢,不使用 union 及子查詢

PRIMARY: 最外層的 select 查詢

UNION: UNION 中的第二個或隨後的 select 查詢,不 依賴於外部查詢的結果集

DERIVED: 用於 from 子句裏有子查詢的情況。 MySQL 會 遞歸執行這些子查詢, 把結果放在臨時表裏。

Table:輸出行所引用的表

Type:從有到差的順序如下:

System-->const-->eq_ref-->ref-->ref_or_null-->index_merge-->unique_subquery-->index_subquery-->range-->index-->all.

各自的含義如下:

system: 表僅有一行(=系統表)。這是 const 連接類型的一個特例。

const: const 用於用常數值比較 PRIMARY KEY 時。當 查詢的表僅有一行時,使用 System。

eq_ref: 從前面的表中，對每一個記錄的聯合都從表中讀取一個記錄，它在查詢使用了索引為主鍵或惟一鍵的全部時使用

ref: 連接不能基於關鍵字選擇單個行,可能查找 到多個符合條件的行。 叫做 ref 是因為索引要 跟某個參考值相比較。這個參考值或者是一 個常數,或者是來自一個表裏的多表查詢的 結果值。

ref_or_null: 如同 ref, 但是 MySQL 必須在初次查找的結果 裏找出 null 條目,然後進行二次查找。

index_merge: 說明索引合並優化被使用了。

unique_subquery: 在某些 IN 查詢中使用此種類型,而不是常規的 ref:valueIN (SELECT primary_key FROM single_table WHERE some_expr)

index_subquery: 在 某 些 IN 查 詢 中 使 用 此 種 類 型 , 與 unique_subquery 類似,但是查詢的是非唯一 性索引

range: 只檢索給定範圍的行,使用一個索引來選擇 行。key 列顯示使用了哪個索引。當使用=、 <>、>、>=、<、<=、IS NULL、<=>、BETWEEN 或者 IN 操作符,用常量比較關鍵字列時,可 以使用 range。

index: 全表掃描,只是掃描表的時候按照索引次序 進行而不是行。主要優點就是避免了排序, 但是開銷仍然非常大。

all: 最壞的情況,從頭到尾全表掃描。

possible_keys : 指出能在該表中使用哪些索引有助於 查詢。如果為空,說明沒有可用的索引。

key:實際從 possible_key 選擇使用的索引。 如果為 NULL,則沒有使用索引。很少的情況 下,MYSQL 會選擇優化不足的索引。這種情 況下,可以在 SELECT 語句中使用 USE INDEX (indexname)來強制使用一個索引或者用IGNORE INDEX(indexname)來強制 MYSQL 忽略索引

key_len: 使用的索引的長度。在不損失精確性的情況 下,長度越短越好。

ref: 顯示索引的哪一列被使用了

rows: 認為必須檢查的用來返回請求數據的行數

extra中出現以下 2 項意味著 根本不能使用索引,效率會受到重大影響。應盡可能對此進行優化。

Using filesort: 表示 會對結果使用一個外部索引排序,而不是從表裏按索引次序讀到相關內容。可能在內存或者磁盤上進行排序。無法利用索引完成的排序操作稱為“文件排序”

Using temporary:表示對查詢結果排序時使用臨時表。常見於排序 order by 和分組查詢group by。

從上述對列名進行介紹,你對性能檢測結果有一個大概的了解了吧.其中type為all的地方,都是需要進行優化的地方.在對sql語句的性能檢測最少也應該到達range,這樣才可以忍受.

當你的工作需要對大量的表進行拼寫的時候,或者你在前期設計表結構的時候,你也可以用explain來檢測你的數據庫表是否是高性能的.別再是拼寫完sql語句就算是完事了,記得要對你的sql語句進行性能檢測,這既是對你自己負責,也是對客戶負責.

既然檢測出來的結果有all ,那麽就需要優化

sql性能分析（explain關鍵字）