再 SQL 優化中，我們經常需要去找那些查詢比較耗時的語句，找到以后我們還要對其進行優化，些時我們常常用到 explain 這個命令來查看一個這些 SQL 語句的執行情況，查看該 SQL 語句有沒有使用上了索引，有沒有做全表掃描，這都可以通過 explain 命令來查看。所以我們深入了解 MySQL 的基于開銷的優化器，還可以獲得很多可能被優化器考慮到的訪問策略的細節，以及當運行 SQL 語句時哪種策略預計會被優化器采用。

使用方法

在 select 語句前加上 explain 就可以了,如

各個屬性的含義

id

select 查詢的序列號；

select_type

select 查詢的類型，主要是區別普通查詢和聯合查詢、子查詢之類的復雜查詢；

table

輸出的行所引用的表；

type

聯合查詢所使用的類型，type 顯示的是訪問類型，是較為重要的一個指標，結果值從好到壞依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge

> unique_subquery > index_subquery > range > index > ALL

一般來說，得保證查詢至少達到range級別，最好能達到 ref

possible_keys

指出MySQL能使用哪個索引在該表中找到行。如果是空的，沒有相關的索引。這時要提高性能，可通過檢驗 WHERE 子句，看是否引用某些字段，或者檢查字段不是適合索引；

key

顯示MySQL實際決定使用的鍵。如果沒有索引被選擇，鍵是 NULL；

key_len

顯示MySQL決定使用的鍵長度。如果鍵是 NULL，長度就是 NULL。文檔提示特別注意這個值可以得出一個多重主鍵里 mysql 實際使用了哪一部分；

ref

顯示哪個字段或常數與 key 一起被使用；

rows

這個數表示 mysql 要遍歷多少數據才能找到，在 innodb 上是不準確的；

Extra

如果是Only index，這意味著信息只用索引樹中的信息檢索出的，這比掃描整個表要快。

如果是where used，就是使用上了where限制。

如果是impossible where 表示用不著where，一般就是沒查出來啥。

如果此信息顯示 Using filesort 或者 Using temporary 的話會很吃力，WHERE和ORDER BY的索引經常無法兼顧，如果按照 WHERE 來確定索引，那么在 ORDER BY 時，就必然會引起 Using filesort，這就要看是先過濾再排序劃算，還是先排序再過濾劃算。

常見的名詞解釋

Using filesort

MySQL需要額外的一次傳遞，以找出如何按排序順序檢索行。

Using index

從只使用索引樹中的信息而不需要進一步搜索讀取實際的行來檢索表中的列信息。

Using temporary

為了解決查詢，MySQL 需要創建一個臨時表來容納結果。

ref

對于每個來自于前面的表的行組合，所有有匹配索引值的行將從這張表中讀取

ALL

完全沒有索引的情況，性能非常地差勁。

index

與 ALL 相同，除了只有索引樹被掃描。這通常比 ALL 快，因為索引文件通常比數據文件小。

SIMPLE

簡單 SELECT，不使用 UNION 或子查詢

explain 手冊查詢

id

SELECT 識別符。這是SELECT的查詢序列號

select_type

SELECT 類型，可以為以下任何一種：

SIMPLE：簡單SELECT(不使用UNION或子查詢)

PRIMARY：最外面的SELECT

UNION：UNION中的第二個或后面的SELECT語句

DEPENDENT UNION：UNION中的第二個或后面的SELECT語句,取決于外面的查詢

UNION RESULT：UNION 的結果

SUBQUERY：子查詢中的第一個SELECT

DEPENDENT SUBQUERY：子查詢中的第一個SELECT,取決于外面的查詢

DERIVED：導出表的SELECT(FROM子句的子查詢)

table

輸出的行所引用的表

type

聯接類型。下面給出各種聯接類型,按照從最佳類型到最壞類型進行排序：

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

const：表最多有一個匹配行,它將在查詢開始時被讀取。因為僅有一行,在這行的列值可被優化器剩余部分認為是常數。const表很快,因為它們只讀取一次!

eq_ref：對于每個來自于前面的表的行組合,從該表中讀取一行。這可能是最好的聯接類型,除了const類型。

ref：對于每個來自于前面的表的行組合,所有有匹配索引值的行將從這張表中讀取。

ref_or_null：該聯接類型如同ref,但是添加了MySQL可以專門搜索包含NULL值的行。

index_merge：該聯接類型表示使用了索引合并優化方法。

unique_subquery：該類型替換了下面形式的IN子查詢的ref： value IN (SELECT primary_key FROM single_table WHERE some_expr) unique_subquery是一個索引查找函數,可以完全替換子查詢,效率更高。

index_subquery：該聯接類型類似于unique_subquery。可以替換IN子查詢,但只適合下列形式的子查詢中的非唯一索引： value IN (SELECT key_column FROM single_table WHERE some_expr)

range：只檢索給定范圍的行,使用一個索引來選擇行。

index：該聯接類型與ALL相同,除了只有索引樹被掃描。這通常比ALL快,因為索引文件通常比數據文件小。

ALL：對于每個來自于先前的表的行組合,進行完整的表掃描。

possible_keys

指出MySQL能使用哪個索引在該表中找到行

key 顯示MySQL實際決定使用的鍵(索引)。如果沒有選擇索引,鍵是NULL。

key_len 顯示MySQL決定使用的鍵長度。如果鍵是NULL,則長度為NULL。

ref 顯示使用哪個列或常數與key一起從表中選擇行。

rows 顯示MySQL認為它執行查詢時必須檢查的行數。多行之間的數據相乘可以估算要處理的行數。

filtered 顯示了通過條件過濾出的行數的百分比估計值。

Extra

該列包含 MySQL 解決查詢的詳細信息

Distinct：MySQL發現第1個匹配行后,停止為當前的行組合搜索更多的行。

Not exists：MySQL能夠對查詢進行LEFT JOIN優化,發現1個匹配LEFT JOIN標準的行后,不再為前面的的行組合在該表內檢查更多的行。

range checked for each record (index map： #)：MySQL沒有發現好的可以使用的索引,但發現如果來自前面的表的列值已知,可能部分索引可以使用。

Using filesort：MySQL需要額外的一次傳遞,以找出如何按排序順序檢索行。

Using index：從只使用索引樹中的信息而不需要進一步搜索讀取實際的行來檢索表中的列信息。

Using temporary：為了解決查詢,MySQL需要創建一個臨時表來容納結果。

Using where：WHERE 子句用于限制哪一個行匹配下一個表或發送到客戶。

Using sort_union(…), Using union(…), Using intersect(…)：這些函數說明如何為index_merge聯接類型合并索引掃描。

Using index for group-by：類似于訪問表的Using index方式,Using index for group-by表示MySQL發現了一個索引,可以用來查 詢GROUP BY或DISTINCT查詢的所有列,而不要額外搜索硬盤訪問實際的表。

總結

以上是生活随笔為你收集整理的explain mysql语句_使用 explain 查看 MySQL 中 SQL 语句的执行情况 - 文章的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。