更多知識,請移步個人小破站:http://hellofriend.topmysql
使用EXPLAIN
關鍵字能夠模擬優化器執行SQL查詢語句,從而知道MySQL是如何處理你的SQL語句的。分析你的查詢語句或是表結構的性能瓶頸。sql
經過Explain
,咱們能夠獲取如下信息:shell
Explain + SQL語句
EXPLAIN SELECT * FROM USER;
select查詢的序列號,包含一組數字,表示查詢中執行select子句或操做表的順序。緩存
id相同,執行順序由上至下。
工具
若是是子查詢,id的序號會遞增。id越大優先級越高,越先被執行。
性能
id若是相同,能夠認爲是一組,從上往下順序執行。在全部組中,id值越大,優先級越高,越先執行。
優化
id號每一個號碼,表示一趟獨立的查詢。一個sql的查詢趟數越少越好。code
查詢的類型,主要是用於區別普通查詢、聯合查詢、子查詢等的複雜查詢。
server
顯示這一行的數據是關於哪張表的。blog
表明分區表中的命中狀況,非分區表,該項爲null。
type顯示的是訪問類型,是較爲重要的一個指標,結果值從最好到最壞依次是:
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
通常來講,得保證查詢至少達到range
級別,最好能達到ref
。
顯示查詢使用了何種類型,從最好到最差依次是:
system > const > eq_ref > ref > range > index > ALL
只檢索給定範圍的行,使用一個索引來選擇行。key 列顯示使用了哪一個索引。通常就是在你的where語句中出現了between、<、>、in等的查詢。
這種範圍掃描索引掃描比全表掃描要好,由於它只須要開始於索引的某一點,而結束語另外一點,不用掃描所有索引。
SQL使用到了索引,可是沒用索引進行過濾。通常是使用到了覆蓋索引或者是使用索引進行排序分組。
Full Table Scan,將遍歷全表以找到匹配的行。
顯示可能應用在這張表中的索引,一個或多個。查詢涉及到的字段上若存在索引,則該索引將被列出,但不必定被查詢實際使用。
實際使用的索引。若是爲NULL,則沒有使用索引。查詢中若使用了覆蓋索引,則該索引和查詢的select字段重疊。
表示索引中使用的字節數,可經過該列計算查詢中使用的索引的長度。key_len字段可以幫你檢查是否充分的利用上了索引。key_len越長,查詢效率越高
。Where條件命中索引的長度,不包含分組排序。
顯示索引的哪一列被使用了,若是可能的話,是一個常數。哪些列或常量被用於查找索引列上的值。
rows列顯示MySQL認爲它執行查詢時必須檢查的行數。行數越少,效率越高!
這個字段表示存儲引擎返回的數據在server層過濾後,剩下多少知足查詢的記錄數量的比例,注意是百分比,不是具體記錄數。
包含不適合在其餘列中顯示但十分重要的額外信息。主要用來檢查分組、排序的時候用沒用到索引。
說明mysql會對數據使用一個外部的索引排序,而不是按照表內的索引順序進行讀取。MySQL中沒法利用索引完成的排序操做稱爲「 文件排序 」。排序的字段沒有建立索引。
使了用臨時表保存中間結果,MySQL在對查詢結果排序時使用臨時表。常見於排序 order by 和分組查詢 group by。分組的時候使用的字段沒有建立索引,分組其實內部包含了一個排序的過程,因此上面的Using filesort 也會出現。
表示相應的select操做中使用了覆蓋索引,避免訪問了表的數據行,效率不錯。
代表使用到了Where過濾。
使用到了鏈接緩存。
where 子句的結果永遠爲false,表示sql語句錯了。
在沒有GROUPBY子句的狀況下,基於索引優化MIN/MAX操做或者 對於MyISAM存儲引擎優化COUNT(*)操做,沒必要等到執行階段再進行計算, 查詢執行計劃生成的階段即完成優化。
本文講述了經過使用Explain
關鍵字進行MySQL語句性能的分析,下篇將更進一步的講解如何進行優化。
本文由博客羣發一文多發等運營工具平臺 OpenWrite 發佈