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

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

        如果测试的过程会修改数据或者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卡)给基准测试带来了很大的挑战。最后，如果测试中出现异常结果，不要轻易当作坏数据点而丢弃。应该认真研究并找到产生这种结果的原因。测试可能会得到有价值的结果，或者一个严重的错误，抑或基准测试的设计缺陷。如果对测试结果不了解，就不要轻易公布。有一些案例表明，异常的测试结果往往都是由于很小的错误导致的，最后搞得测试无功而返。