一、explain簡介
使用EXPLAIN關鍵字可以模擬優化器執行SQL查詢語句,從而知道MySQL是如何處理你的SQL語句的。分析你的查詢語句或是表結構的性能瓶頸。
➤ 通過EXPLAIN,我們可以分析出以下結果:
- 表的讀取順序
- 數據讀取操作的操作類型
- 哪些索引可以使用
- 哪些索引被實際使用
- 表之間的引用
- 每張表有多少行被優化器查詢
➤ 使用方式如下:
EXPLAIN +SQL語句
EXPLAIN SELECT * FROM t1
執行計劃包含的信息
二、執行計劃各字段含義
2.1 id
select查詢的序列號,包含一組數字,表示查詢中執行select子句或操作表的順序
id的結果共有3中情況
-
id相同,執行順序由上至下
[總結] 加載表的順序如上圖table列所示:t1 t2 t3 -
id不同,如果是子查詢,id的序號會遞增,id值越大優先級越高,越先被執行
-
id相同不同,同時存在
如上圖所示,在id爲1時,table顯示的是 <derived2> ,這裏指的是指向id爲2的表,即t3表的衍生表。
2.2 select_type
常見和常用的值有如下幾種:
分別用來表示查詢的類型,主要是用於區別普通查詢、聯合查詢、子查詢等的複雜查詢。
-
SIMPLE 簡單的select查詢,查詢中不包含子查詢或者UNION
-
PRIMARY 查詢中若包含任何複雜的子部分,最外層查詢則被標記爲PRIMARY
-
SUBQUERY 在SELECT或WHERE列表中包含了子查詢
-
DERIVED 在FROM列表中包含的子查詢被標記爲DERIVED(衍生),MySQL會遞歸執行這些子查詢,把結果放在臨時表中
-
UNION 若第二個SELECT出現在UNION之後,則被標記爲UNION:若UNION包含在FROM子句的子查詢中,外層SELECT將被標記爲:DERIVED
-
UNION RESULT 從UNION表獲取結果的SELEC
2.3 table
指的就是當前執行的表
2.4 type
type所顯示的是查詢使用了哪種類型,type包含的類型包括如下圖所示的幾種:
從最好到最差依次是
system > const > eq_ref > ref > range > index > all
一般來說,得保證查詢至少達到range級別,最好能達到ref。
-
system 表只有一行記錄(等於系統表),這是const類型的特列,平時不會出現,這個也可以忽略不計
-
const 表示通過索引一次就找到了,const用於比較primary key 或者unique索引。因爲只匹配一行數據,所以很快。如將主鍵置於where列表中,MySQL就能將該查詢轉換爲一個常量。
首先進行子查詢得到一個結果的d1臨時表,子查詢條件爲id = 1 是常量,所以type是const,id爲1的相當於只查詢一條記錄,所以type爲system。 -
eq_ref 唯一性索引掃描,對於每個索引鍵,表中只有一條記錄與之匹配。常見於主鍵或唯一索引掃描
-
ref 非唯一性索引掃描,返回匹配某個單獨值的所有行,本質上也是一種索引訪問,它返回所有匹配某個單獨值的行,然而,它可能會找到多個符合條件的行,所以他應該屬於查找和掃描的混合體。
-
range 只檢索給定範圍的行,使用一個索引來選擇行,key列顯示使用了哪個索引,一般就是在你的where語句中出現between、< 、>、in等的查詢,這種範圍掃描索引比全表掃描要好,因爲它只需要開始於索引的某一點,而結束於另一點,不用掃描全部索引。
-
index Full Index Scan,Index與All區別爲index類型只遍歷索引樹。這通常比ALL快,因爲索引文件通常比數據文件小。(也就是說雖然all和Index都是讀全表,但index是從索引中讀取的,而all是從硬盤讀取的)
id是主鍵,所以存在主鍵索引 -
all Full Table Scan 將遍歷全表以找到匹配的行
2.5 possible_keys 和 key
possible_keys 顯示可能應用在這張表中的索引,一個或多個。查詢涉及到的字段上若存在索引,則該索引將被列出,但不一定被查詢實際使用。
key
- 實際使用的索引,如果爲NULL,則沒有使用索引。(可能原因包括沒有建立索引或索引失效)
- 查詢中若使用了覆蓋索引(select 後要查詢的字段剛好和創建的索引字段完全相同),則該索引僅出現在key列表中
2.6 key_len
表示索引中使用的字節數,可通過該列計算查詢中使用的索引的長度,在不損失精確性的情況下,長度越短越好。key_len顯示的值爲索引字段的最大可能長度,並非實際使用長度,即key_len是根據表定義計算而得,不是通過表內檢索出的。
2.7 ref
顯示索引的那一列被使用了,如果可能的話,最好是一個常數。哪些列或常量被用於查找索引列上的值。
2.8 rows
根據表統計信息及索引選用情況,大致估算出找到所需的記錄所需要讀取的行數,也就是說,用的越少越好
2.9 Extra
包含不適合在其他列中顯式但十分重要的額外信息
(1)、Using filesort(九死一生)
說明mysql會對數據使用一個外部的索引排序,而不是按照表內的索引順序進行讀取。MySQL中無法利用索引完成的排序操作稱爲“文件排序”。
(2)、Using temporary(十死無生)
使用了用臨時表保存中間結果,MySQL在對查詢結果排序時使用臨時表。常見於排序order by和分組查詢group by。
(3)、Using index(發財了)
表示相應的select操作中使用了覆蓋索引(Covering Index),避免訪問了表的數據行,效率不錯。如果同時出現using where,表明索引被用來執行索引鍵值的查找;如果沒有同時出現using where,表明索引用來讀取數據而非執行查找動作。
(4)、Using where
表明使用了where過濾
(5)、Using join buffer
表明使用了連接緩存,比如說在查詢的時候,多表join的次數非常多,那麼將配置文件中的緩衝區的join buffer調大一些。
(6)、impossible where
where子句的值總是false,不能用來獲取任何元組
SELECT * FROM t_user WHERE id = '1' and id = '2'
(7)、select tables optimized away
在沒有GROUPBY子句的情況下,基於索引優化MIN/MAX操作或者對於MyISAM存儲引擎優化COUNT(*)操作,不必等到執行階段再進行計算,查詢執行計劃生成的階段即完成優化。
(8)、distinct
優化distinct操作,在找到第一匹配的元組後即停止找同樣值的動作
3. 實例分析
- 執行順序1:select_type爲UNION,說明第四個select是UNION裏的第二個select,最先執行【select name,id from t2】
- 執行順序2:id爲3,是整個查詢中第三個select的一部分。因查詢包含在from中,所以爲DERIVED【select id,name from t1 where other_column=”】
- 執行順序3:select列表中的子查詢select_type爲subquery,爲整個查詢中的第二個select【select id from t3】
- 執行順序4:id列爲1,表示是UNION裏的第一個select,select_type列的primary表示該查詢爲外層查詢,table列被標記爲<derived3>,表示查詢結果來自一個衍生表,其中derived3中的3代表該查詢衍生自第三個select查詢,即id爲3的select。【select d1.name ……】
- 執行順序5:代表從UNION的臨時表中讀取行的階段,table列的< union1,4 >表示用第一個和第四個select的結果進行UNION操作。【兩個結果union操作】
轉載來自:https://blog.csdn.net/why15732625998/article/details/80388236