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