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