一旦掌握并实践面向响应时间的优化方法，就会发现需要不断地对系统进行性能剖析(profiling)。性能剖析是测量和分析时间花费在哪里的主要方法。性能剖析一般有两个步骤:测量任务所花费的时间;然后对结果进行统计和排序，将重要的任务排到前面。
性能剖析工具的工作方式基本相同。在任务开始时启动计时器，在任务结束时停止计时器，然后用结東时间减去启动时间得到响应时间。也有些工具会记录任务的父任务。这些结果数据可以用来绘制调用关系图，但对于我们的目标来说更重要的是，可以将相似的任务分组并进行汇总。对相似的任务分组并进行汇总可以有帮助对那些分到组的任务做更复杂的统计分析，但至少需要知道每组有多少任务，并计算出总的响应时间。通过性能剖析报告(profile report)可以获得需要的结果。性能剖析报告会列出所有任务列表。每行记录一个任务， 包括任务名、任务的执行时间、任务的消耗时间、任务的平均执行时间，以及该任务执行时间占全部时间的百分比。性能剖析报告会按照任务的消耗时间进行降序排序。
为了更好地说明，这里举一个对整个数据库美国服务器工作负载的性能剖析的例子，主要输出的是各种类型的查询和执行查询的时间。这是从整体的角度来分析响应时间，后面会演示其他角度的分析结果。下面的输出是用Percona Toolkit 中的pt-query-digest (实际上就是著名的Maatkit工具中的mk-query-digest)分析得到的结果。为了显示方便，对结果做了一些微调，并且只截取了前面几行结果:
Rank Response time
Calls R/Call Item
==== ================ ===== ====== =======
1 11256.3618 68.1% 78069 0.1442 SELECT InvitesNew
2 2029.4730 12.3% 14415 0.1408 SELECT StatusUpdate
3 1345.3445 8.1% 3520 0.3822 SHOW STATUS
上面只是性能制析结果的前几行， 根据总响应时间进行排名，只包括剖析所需要的最小列组合。每一行都包括了查询的响应时间和占总时间的百分比、查询的执行次数、单次执行的平均响应时间，以及该查询的摘要。通过这个性能剖析可以很清楚地看到每个查询相互之间的成本比较，以及每个查询占总成本的比较。在这个例子中，任务指的就是查询，实际上在分析MySQL的时候经常都指的是查询。
我们将实际地讨论两种类型的性能剖析:基于执行时间的分析和基于等待的分析。基于执行时间的分析研究的是什么任务的执行时间最长，而基于等待的分析则是判断任务在什么地方被阻塞的时间最长。
如果任务执行时间长是因为消耗了太多的资源且大部部分时间花费在执行上，等待的时间不多，这种情况下基于等待的分析作用就不大。反之亦然，如果任务一直在等待， 没有消耗什么资源，去分析执行时间就不会有什么结果。如果不能确认问题是出在执行还是等待上，那么两种方式都需要试试。后面会给出详细的例子。
事实上，当基于执行时间的分析发现一个任务课后要花费太多时间的时候，应该深人去分析一下，可能会发现某些“执行时间”实际上是在等待。例如，上面简单的性能剖析的输出显示表InvitesNew上的SELECT查询花费了大量时间，如果深人研究，则可能发现时间都花费在等待I/O完成上。
在对系统进行性能剖析前，必须先要能够进行测量，这需要系统可测量化的支持。可测量的系统般会有多 个测量点可以捕获井收集数据，但实际系统很少可以做到可测量化。大部分系统都没有多少可测量点，即使有也只提供些话 动的计数，而没有活动花费的时间统计。MySQL就是一个典型的例子，直到版本5.5 才第一次提供了PerformanceSchema,其中有些基 于时间的测量点4，而版本s.1及之前的版本没有任何基于时间的测量点。能够从MySQL收集到的美国服务器操作的数据大多是show status计数器的形式，这些计数器统计的是某种活动发生的次數。这也是我们最终决定创建Percona Server的主要原因，Percona Server从版本5.0开始提供很多更详细的查询级别的测量点。
虽然理想的性能优化技术依赖于更多的测量点，但幸运的是，即使系统没有提供测量点，也还有其他办法可以展开优化工作。因为还可以从外部去测量系统，如果测量失败，也可以根据对系统的了解做出一些靠谱的猜测。但这么做的时候一定要记住， 不管是外部测量还是猜测，数据都不是百分之百准确的，这是系统不透明所带来的风险。
举个例子，在Percona Server 5.0中，慢查询日志揭露了一些性能低下的原因，如磁盘IO等待或者行级锁等待。如果日志中显示一条查询花费 10秒，其中9.6秒在等待磁盘IO,那么追究其他4%的时间花费在哪里就没有意义，磁盘I/O才是最重要的原因。
