剖析單條查詢（）
剖析報告給出了查詢執行的每個步驟及其花費的時間看結果很難快速地確定哪個步驟花費的時間最多因為輸出是按照執行順序排序而不是按花費的時間排序的而實際上我們更關心的是花費了多少時間這樣才能知道哪些開銷比較大但不幸的是無法通過諸如ORDER BY 之類的命令重新排序假如不使用SHOW PROFILE 命令而是直接查詢INFORMATION_SCHEMA 中對應的表則可以按照需要格式化輸出
mysql> SET @query_id = ;
Query OK rows affected （ sec）
mysql> SELECT STATE SUM（DURATION） AS Total_R
| Chapter :Profiling Server Performance
wwwitebooksinfo
> ROUND（
> * SUM（DURATION） /
> （SELECT SUM（DURATION）
> FROM INFORMATION_SCHEMAPROFILING
> WHERE QUERY_ID = @query_id
> ） ） AS Pct_R
> COUNT（*） AS Calls
> SUM（DURATION） / COUNT（*） AS R/Call
> FROM INFORMATION_SCHEMAPROFILING
> WHERE QUERY_ID = @query_id
> GROUP BY STATE
> ORDER BY Total_R DESC;
++++++
| STATE | Total_R | Pct_R | Calls | R/Call |
++++++
| Copying to tmp table | | | | |
| Sending data | | | | |
| Sorting result | | | | |
| removing tmp table | | | | |
| logging slow query | | | | |
| checking permissions | | | | |
| Creating tmp table | | | | |
| Opening tables | | | | |
| statistics | | | | |
| starting | | | | |
| preparing | | | | |
| freeing items | | | | |
| optimizing | | | | |
| init | | | | |
| Table lock | | | | |
| closing tables | | | | |
| System lock | | | | |
| executing | | | | |
| end | | | | |
| cleaning up | | | | |
| query end | | | | |
++++++
效果好多了！通過這個結果可以很容易看到查詢時間太長主要是因為花了一大半的時間在將數據復制到臨時表這一步那麼優化就要考慮如何改寫查詢以避免使用臨時表或者提升臨時表的使用效率第二個消耗時間最多的是發送數據（Sending data）這個狀態代表的原因非常多可能是各種不同的服務器活動包括在關聯時搜索匹配的行記錄等這部分很難說能優化節省多少消耗的時間另外也要注意到結果排序（Sortingresult）花費的時間占比非常低所以這部分是不值得去優化的這是一個比較典型的問題所以一般我們都不建議用戶在優化排序緩沖區（tuning sort buffers）或者類似的活動上花時間
盡管剖析報告能幫助我們定位到哪些活動花費了最多的時間但並不會告訴我們為什麼會這樣要弄清楚為什麼復制數據到臨時表要花費這麼多時間就需要深入下去繼續剖析這一步的子任務
[] []
From:http://tw.wingwit.com/Article/program/MySQL/201311/29708.html
