1.生成執行計劃
生成的方法很簡單在相應的select語句前面加explain即可
2.查看執行計劃
字段 |
解釋 |
Id |
包含一組數字,表示查詢中執行select子句或操作表的順序,執行順序從大到小執行,當id值一樣的時候,執行順序由上往下 |
Select_type |
表示查詢中每個select子句的類型(簡單OR複雜) |
Type |
表示MySQL在表中找到所需行的方式,又稱“訪問類型” |
possible_keys |
指出MySQL能使用哪個索引在表中找到行,查詢涉及到的字段上若存在索引,則該索引將被列出,但不一定被查詢使用 |
key |
顯示MySQL在查詢中實際使用的索引,若沒有使用索引,顯示爲NULL。當查詢中若使用了覆蓋索引,則該索引僅出現在key列表中 |
key_len |
表示索引中使用的字節數,可通過該列計算查詢中使用的索引的長度 |
ref |
表示上述表的連接匹配條件,即那些列或常量被用於查找索引列上的值 |
rows |
表示MySQL根據表統計信息及索引選用情況,估算的找到所需的記錄所需要讀取的行數 |
Extra |
包含不適合在其他列中顯示但十分重要的額外信息 |
select子句的類型 |
解釋 |
SIMPLE |
查詢中不包含子查詢或者UNION |
PRIMARY |
查詢中若包含任何複雜的子部分,最外層查詢則被標記爲PRIMARY |
SUBQUERY |
在SELECT或WHERE列表中包含了子查詢,該子查詢被標記爲SUBQUERY |
DERIVED |
在FROM列表中包含的子查詢被標記爲DERIVED(衍生),若第二個SELECT出現在UNION之後,則被標記爲UNION;若UNION包含在FROM子句的子查詢中,外層SELECT將被標記爲:DERIVED從UNION表獲取結果的SELECT被標記爲:UNION RESULT |
Type訪問類型 |
解釋 |
ALL |
Full Table Scan, MySQL將進行全表掃描 |
index |
Full Index Scan,index與ALL區別爲index類型只遍歷索引樹 |
range |
range Index Scan,對索引的掃描開始於某一點,返回匹配值域的行,常見於between、<、>等的查詢 |
ref |
非唯一性索引掃描,返回匹配摸個單獨值的所有行。常見於使用非唯一索引或唯一索引的非唯一前綴進行的查找 |
eq_ref |
唯一性索引掃描,對於每個索引鍵,表中只有一條記錄與之匹配。常見於主鍵或唯一索引掃描 |
const、system |
當MySQL對查詢某部分進行優化,並轉換爲一個常量時,使用這些類型訪問。如將主鍵置於where列表中,MySQL就能將該查詢轉換爲一個常量 |
NULL |
MySQL在優化過程中分解語句,執行時甚至不用訪問表或索引 |
Extra額外信息 |
解釋 |
Using where |
表示MySQL服務器在存儲引擎受到記錄後進行“後過濾”(Post-filter),如果查詢未能使用索引,Using where的作用只是提醒我們MySQL將用where子句來過濾結果集 |
Using temporary |
表示MySQL需要使用臨時表來存儲結果集,常見於排序和分組查詢 |
Using filesort |
MySQL中無法利用索引完成的排序操作稱爲“文件排序” |
3.mysql執行計劃的侷限
EXPLAIN不會告訴你關於觸發器、存儲過程的信息或用戶自定義函數對查詢的影響情況
EXPLAIN不考慮各種Cache
EXPLAIN不能顯示MySQL在執行查詢時所作的優化工作
部分統計信息是估算的,並非精確值
EXPALIN只能解釋SELECT操作,其他操作要重寫爲SELECT後查看執行計劃
4.對於非select語句查看執行計劃
在實際的工作中也經常需要查看一些諸如update、delete的執行計劃,(mysql5.6的版本已經支持直接查看)但是這時候並不能直接通過explain來進行查看,而需要通過改寫語句進行查看執行計劃
在一個生產數據庫的慢查詢日誌發現有條語句如下:
Count: 13 Time=73.44s (954s) Lock=0.00s (0s) Rows=0.0 (0), ipos[ipos]@2hostsupdate ipos_zdjhd m,ipos_zdjhdtj tj set m.qr=N,m.qrrq=‘S’,m.qrr=‘S’,tj.qr=N,tj.qrrq='S’where m.ydjh=‘S’ and tj.djbh=‘S’ |
可以改寫如下:
Explain Select m.qr , m.qrr , tj.qr , tj.qrrq from ipos_zdjhd m,ipos_zdjhdtj tj where m.ydjh='17233' and tj.djbh='48632';
馬上可以發現ipos_zdjhd表進行了全表掃描,而ipos_zdjhd表有1076971行的數據,所以整個update的操作肯定是一個很慢的過程,經過和開發人員溝通後,在ipos_zdjhd表增加相應的索引便讓整個過程提升了500倍。執行計劃加上慢查詢日誌組成了mysql調優過程的一組調優利器,當數據庫穩定過後參數的調優是很少的一部分,80%以上的調優都會是SQL調優