剖析单条查询（）
剖析报告给出了查询执行的每个步骤及其花费的时间看结果很难快速地确定哪个步骤花费的时间最多因为输出是按照执行顺序排序而不是按花费的时间排序的而实际上我们更关心的是花费了多少时间这样才能知道哪些开销比较大但不幸的是无法通过诸如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）或者类似的活动上花时间
尽管剖析报告能帮助我们定位到哪些活动花费了最多的时间但并不会告诉我们为什么会这样要弄清楚为什么复制数据到临时表要花费这么多时间就需要深入下去继续剖析这一步的子任务
[] []
![高性能MySQL：剖析单条查询（2）[1]](/UploadFiles/2.jpg)