理解性能剖析
MySQL 的性能剖析（profile）将最重要的任务展示在前面但有时候没显示出来的信息也很重要可以参考一下前面提到过的性能剖析的例子不幸的是尽管性能剖析输出了排名总计和平均值但还是有很多需要的信息是缺失的如下所示
值得优化的查询（worthwhile queries）
性能剖析不会自动给出哪些查询值得花时间去优化这把我们带回到优化的本意如果你读过Cary Millsap 的书对此就会有更多的理解这里我们要再次强调两点第一 一些只占总响应时间比重很小的查询是不值得优化的根据阿姆达尔定律（Amdahls Law）对一个占总响应时间不超过% 的查询进行优化无论如何努力收益也不会超过%第二如果花费了 美元去优化一个任务但业务的收入没有任何增加那么可以说反而导致业务被逆优化了 美元如果优化的成本大于收益就应当停止优化
异常情况
某些任务即使没有出现在性能剖析输出的前面也需要优化比如某些任务执行次数很少但每次执行都非常慢严重影响用户体验因为其执行频率低所以总的响应时间占比并不突出
未知的未知
一款好的性能剖析工具会显示可能的丢失的时间丢失的时间指的是任务的总时间和实际测量到的时间之间的差例如如果处理器的CPU 时间是 秒而剖析到的任务总时间是 秒那么就有 毫秒的丢失时间这可能是有些任务没有测量到也可能是由于测量的误差和精度问题的缘故如果工具发现了这类问题则要引起重视因为有可能错过了某些重要的事情即使性能剖析没有发现丢失时间也需要注意考虑这类问题存在的可能性这样才不会错过重要的信息我们的例子中没有显示丢失的时间这是我们所使用工具的一个局限性
被掩藏的细节
性能剖析无法显示所有响应时间的分布只相信平均值是非常危险的它会隐藏很多信息而且无法表达全部情况Peter 经常举例说医院所有病人的平均体温没有任何价值注假如在前面的性能剖析的例子的第一项中如果有两次查询的响应时间是 秒而另外 次查询的响应时间是几十微秒结果会怎样？只从平均值里是无法发现两次 秒的查询的要做出最好的决策需要为性能剖析里输出的这一行中包含的 次查询提供更多的信息尤其是更多响应时间的信息比如直方图百分比标准差偏差指数等
好的工具可以自动地获得这些信息实际上ptquerydigest 就在剖析的结果里包含了很多这类细节信息并且输出在剖析报告中对此我们做了简化可以将精力集中在重要而基础的例子上通过排序将最昂贵的任务排在前面本章后面会展示更多丰富而有用的性能剖析的例子
在前面的性能剖析的例子中还有一个重要的缺失就是无法在更高层次的堆栈中进行交互式的分析当我们仅仅着眼于服务器中的单个查询时无法将相关查询联系起来也无法理解这些查询是否是同一个用户交互的一部分性能剖析只能管中窥豹而无法将剖析从任务扩展至事务或者页面查看（page view）的级别也有一些办法可以解决这个问题比如给查询加上特殊的注释作为标签可以标明其来源并据此做聚合也可以在应用层面增加更多的测量点这是下一节的主题
返回目录高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
Oracle索引技术
