当获得台湾云服务器或者查询的剖析报告后，怎么使用?好的剖析报告能够将潜在的问题显示出来，但最终的解决方案还需要用户来决定(尽管报告可能会给出建议)。优化查询时用户需要对台湾云服务器如何执行查询有较深的了解。剖析报告能够尽可能多地收集需要的信息、给出诊断问题的正确方向，以及为其他诸如EXPLAIN等工具提供基础信息。这里厂是先引出话题，后续将继续讨论。

        尽管一个拥有完整测量信息的剖析报告可以让事情变得简单，但现有系统通常都没有完美的测量支持。从前面的例子来说，我们虽然推断出是临时表和没有索引的读导致查询的响应时间过长，但却没有明确的证据。因为无法测最所有需要的信息，或者测量的范围不正确。有些问题就很难解决。 例如，可能没有集中在需要优化的地方测量，而是测量了台湾云服务器层面的活动，或者测量的是查询开始之前的计数器，而不是查询开始后的数据。

        也有其他的可能性。设想一下正在分析慢查询日志，发现了一个很简单的查询正常情况下都非常快，却有几次非常不合理地执行了很长时间。手工重新执行一遍，发现也非常快，然后使用EXPLAIN查询其执行计划，也正确地使用了索引。然后尝试修改WHeRE条件中使用不同的值，以排除缓存命中的可能，也没有发现有什么问题，这可能是什么原因呢?

        如果使用官方版本的 MySQL,慢查询日志中没有执行计划或者详细的时间信息，对于偶尔记录到的这几次查询异常慢的问题，很难知道其原因在哪里， 因为信息有限。可能是系统中有其他东西消耗了资源，比如正在备份，也可能是某种类型的锁或者争用阻塞了查询的进度。这种间歇性的问题将在后续详细讨论。