MySQL美国服务器的性能剖析(profile) 将最重要的任务展示在前面，但有时候没显示出来的信息也很重要。可以参考一下前面提到过的性能剖析的例子。不幸的是，尽管性能剖析输出了排名、总计和平均值，但还是有很多需要的信息是缺失的，如下所示。
值得优化的查询(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)的级别。也有一些办法可以解决心个问题，比如给查询加上特殊的注释作为标签，可以标明其来源并据此做聚合，也可以在应用层面增加更多的测量点。
