每次抓取数据都会先记录当前的时间戳，所以可以在文件中搜索某个时间点的数据。也可以写一些awk 或者sed 脚本来简化操作。

　　这个脚本不会处理或者过滤收集到的数据。先收集所有的原始数据，然后再基于此做分析和过滤是一个好习惯。如果在收集的时候对数据做了预处理，而后续分析发现一些异常的地方需要用到更多的原始数据，这时候就要“抓瞎”了。

　　如果需要在测试完成后脚本自动退出，只需要删除/home/benchmarks/running 文件即可。

　　这只是一段简单的代码，或许不能满足全部的需求，但却很好地演示了该如何捕获测试的性能和状态数据。从代码可以看出，只捕获了MySQL 的部分数据，如果需要，则很容易通过修改脚本添加新的数据捕获。例如，可以通过pt-diskstats 工具注5 捕获/proc/diskstats 的数据为后续分析磁盘I/O 使用。

　　3.4 获得准确的测试结果

　　获得准确测试结果的最好办法，是回答一些关于基准测试的基本问题：是否选择了正确的基准测试？是否为问题收集了相关的数据？是否采用了错误的测试标准？例如，是否对一个I/O 密集型（I/O-bound）的应用，采用了CPU 密集型（CPU-bound）的测试标准来评估性能？

　　接着，确认测试结果是否可重复。每次重新测试之前要确保系统的状态是一致的。如果是非常重要的测试，甚至有必要每次测试都重启系统。一般情况下，需要测试的是经过预热的系统，还需要确保预热的时间足够长（请参考前面关于基准测试需要运行多长时间的内容）、是否可重复。如果预热采用的是随机查询，那么测试结果可能就是不可重复的。

　　如果测试的过程会修改数据或者schema，那么每次测试前，需要利用快照还原数据。在表中插入1 000 条记录和插入100 万条记录，测试结果肯定不会相同。数据的碎片度和在磁盘上的分布，都可能导致测试是不可重复的。一个确保物理磁盘数据的分布尽可能一致的办法是，每次都进行快速格式化并进行磁盘分区复制。

　　要注意很多因素，包括外部的压力、性能分析和监控系统、详细的日志记录、周期性作业，以及其他一些因素，都会影响到测试结果。一个典型的案例，就是测试过程中突然有cron 定时作业启动，或者正处于一个巡查读取周期（Patrol Read cycle），抑或RAID卡启动了定时的一致性检查等。要确保基准测试运行过程中所需要的资源是专用于测试的。如果有其他额外的操作，则会消耗网络带宽，或者测试基于的是和其他服务器共享的SAN 存储，那么得到的结果很可能是不准确的。

　　每次测试中，修改的参数应该尽量少。如果必须要一次修改多个参数，那么可能会丢失一些信息。有些参数依赖其他参数，这些参数可能无法单独修改。有时候甚至都没有意识到这些依赖，这给测试带来了复杂性。

　　一般情况下，都是通过迭代逐步地修改基准测试的参数，而不是每次运行时都做大量的修改。举个例子，如果要通过调整参数来创造一个特定行为，可以通过使用分治法（divide-and-conquer，每次运行时将参数对分减半）来找到正确的值。

　　很多基准测试都是用来做预测系统迁移后的性能的，比如从Oracle 迁移到MySQL。这种测试通常比较麻烦，因为MySQL 执行的查询类型与Oracle 完全不同。如果想知道在Oracle 运行得很好的应用迁移到MySQL 以后性能如何，通常需要重新设计MySQL 的schema 和查询（在某些情况下，比如，建立一个跨平台的应用时，可能想知道同一条查询是如何在两个平台运行的，不过这种情况并不多见）。

　　另外，基于MySQL 的默认配置的测试没有什么意义，因为默认配置是基于消耗很少内存的极小应用的。有时候可以看到一些MySQL 和其他商业数据库产品的对比测试，结果很让人尴尬，可能就是MySQL 采用了默认配置的缘故。让人无语的是，这样明显有误的测试结果还容易变成头条新闻。

　　固态存储（SSD 或者PCI-E 卡）给基准测试带来了很大的挑战，第9 章将进一步讨论。最后，如果测试中出现异常结果，不要轻易当作坏数据点而丢弃。应该认真研究并找到产生这种结果的原因。测试可能会得到有价值的结果，或者一个严重的错误，抑或基准测试的设计缺陷。如果对测试结果不了解，就不要轻易公布。有一些案例表明，异常的测试结果往往都是由于很小的错误导致的，最后搞得测试无功而返。

　　3.5 运行基准测试并分析结果

　　一旦准备就绪，就可以着手基准测试，收集和分析数据了。

　　通常来说，自动化基准测试是个好主意。这样做可以获得更精确的测试结果。因为自动化的过程可以防止测试人员偶尔遗漏某些步骤，或者误操作。另外也有助于归档整个测试过程。

　　自动化的方式有很多，可以是一个Makefile 文件或者一组脚本。脚本语言可以根据需要选择：shell、PHP、Perl 等都可以。要尽可能地使所有测试过程都自动化，包括装载数据、系统预热、执行测试、记录结果等。

　　一旦设置了正确的自动化操作，基准测试将成为一步式操作。如果只是针对某些应用做一次性的快速验证测试，可能就没必要做自动化。但只要未来可能会引用到测试结果，建议都尽量地自动化。否则到时候可能就搞不清楚是如何获得这个结果的，也不记得采用了什么参数，这样就很难再通过测试重现结果了。