大氣全屏通用企業(yè)網站整站源碼沈陽seo優(yōu)化新勢力
?一、EXPLAIN簡介
使用EXPLAIN關鍵字可以模擬優(yōu)化器執(zhí)行SQL查詢語句,從而知道MySQL是如何處理你的SQL語句的。分析你的查詢語句或是表結構的性能瓶頸。
(1) 通過EXPLAIN,我們可以分析出以下結果:
- 表的讀取順序
- 數據讀取操作的操作類型
- 哪些索引可以使用
- 哪些索引被實際使用
- 表之間的引用
- 每張表有多少行被優(yōu)化器查詢
(2)使用方式如下:
EXPLAIN +SQL語句
EXPLAIN SELECT * FROM t1
(3)執(zhí)行計劃包含的信息
二、執(zhí)行計劃各字段含義
2.1 id
select查詢的序列號,包含一組數字,表示查詢中執(zhí)行select子句或操作表的順序
id的結果共有3中情況
-
id相同,執(zhí)行順序由上至下?
[總結]?加載表的順序如上圖table列所示:t1 t3 t2
-
id不同,如果是子查詢,id的序號會遞增,id值越大優(yōu)先級越高,越先被執(zhí)行
- id相同不同,同時存在?
?如上圖所示,在id為1時,table顯示的是?
<derived2>
?,這里指的是指向id為2的表,即t3表的衍生表。
2.2 select_type
常見和常用的值有如下幾種:
分別用來表示查詢的類型,主要是用于區(qū)別普通查詢、聯合查詢、子查詢等的復雜查詢。
- SIMPLE 簡單的select查詢,查詢中不包含子查詢或者UNION
- PRIMARY 查詢中若包含任何復雜的子部分,最外層查詢則被標記為PRIMARY
- SUBQUERY 在SELECT或WHERE列表中包含了子查詢
- DERIVED 在FROM列表中包含的子查詢被標記為DERIVED(衍生),MySQL會遞歸執(zhí)行這些子查詢,把結果放在臨時表中
- UNION 若第二個SELECT出現在UNION之后,則被標記為UNION:若UNION包含在FROM子句的子查詢中,外層SELECT將被標記為:DERIVED
- UNION RESULT 從UNION表獲取結果的SELECT
2.3 table
指的就是當前執(zhí)行的表
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區(qū)別為index類型只遍歷索引樹。這通常比ALL快,因為索引文件通常比數據文件小。(也就是說雖然all和Index都是讀全表,但index是從索引中讀取的,而all是從硬盤讀取的)
id是主鍵,所以存在主鍵索引
all
?Full Table Scan 將遍歷全表以找到匹配的行
2.5 possible_keys 和 key
possible_keys 顯示可能應用在這張表中的索引,一個或多個。查詢涉及到的字段上若存在索引,則該索引將被列出,但不一定被查詢實際使用。
key
- 實際使用的索引,如果為NULL,則沒有使用索引。(可能原因包括沒有建立索引或索引失效)
- 查詢中若使用了
覆蓋索引
(select 后要查詢的字段剛好和創(chuàng)建的索引字段完全相同),則該索引僅出現在key列表中?
2.6 key_len
表示索引中使用的字節(jié)數,可通過該列計算查詢中使用的索引的長度,在不損失精確性的情況下,長度越短越好
。key_len顯示的值為索引字段的最大可能長度,并非實際使用長度,即key_len是根據表定義計算而得,不是通過表內檢索出的。
2.7 ref
顯示索引的那一列被使用了,如果可能的話,最好是一個常數。哪些列或常量被用于查找索引列上的值。
2.8 rows
根據表統計信息及索引選用情況,大致估算出找到所需的記錄所需要讀取的行數,也就是說,用的越少越好
2.9 Extra
包含不適合在其他列中顯式但十分重要的額外信息
2.9.1 Using filesort(九死一生)
說明mysql會對數據使用一個外部的索引排序,而不是按照表內的索引順序進行讀取。MySQL中無法利用索引完成的排序操作稱為“文件排序”。
2.9.2 Using temporary(十死無生)
使用了用臨時表保存中間結果,MySQL在對查詢結果排序時使用臨時表。常見于排序order by和分組查詢group by。
2.9.3 Using index(發(fā)財了)
表示相應的select操作中使用了覆蓋索引(Covering Index),避免訪問了表的數據行,效率不錯。如果同時出現using where,表明索引被用來執(zhí)行索引鍵值的查找;如果沒有同時出現using where,表明索引用來讀取數據而非執(zhí)行查找動作。
2.9.4 Using where
表明使用了where過濾
2.9.5 Using join buffer
表明使用了連接緩存,比如說在查詢的時候,多表join的次數非常多,那么將配置文件中的緩沖區(qū)的join buffer調大一些。
2.9.6 impossible where
where子句的值總是false,不能用來獲取任何元組
SELECT * FROM t_user WHERE id = '1' and id = '2'
2.9.7 select tables optimized away
在沒有GROUPBY子句的情況下,基于索引優(yōu)化MIN/MAX操作或者對于MyISAM存儲引擎優(yōu)化COUNT(*)操作,不必等到執(zhí)行階段再進行計算,查詢執(zhí)行計劃生成的階段即完成優(yōu)化。
2.9.8 distinct
優(yōu)化distinct操作,在找到第一匹配的元組后即停止找同樣值的動作
三、實例分析
- 執(zhí)行順序1:select_type為UNION,說明第四個select是UNION里的第二個select,最先執(zhí)行【select name,id from t2】
- 執(zhí)行順序2:id為3,是整個查詢中第三個select的一部分。因查詢包含在from中,所以為DERIVED【select id,name from t1 where other_column=’’】
- 執(zhí)行順序3:select列表中的子查詢select_type為subquery,為整個查詢中的第二個select【select id from t3】
- 執(zhí)行順序4:id列為1,表示是UNION里的第一個select,select_type列的primary表示該查詢?yōu)橥鈱硬樵?#xff0c;table列被標記為<derived3>,表示查詢結果來自一個衍生表,其中derived3中的3代表該查詢衍生自第三個select查詢,即id為3的select。【select d1.name …】
- 執(zhí)行順序5:代表從UNION的臨時表中讀取行的階段,table列的< union1,4 >表示用第一個和第四個select的結果進行UNION操作。【兩個結果union操作】