获得准确的测试结果
获得准确测试结果的最好办法是回答一些关于基准测试的基本问题是否选择了正确的基准测试？是否为问题收集了相关的数据？是否采用了错误的测试标准？例如是否对一个I/O 密集型（I/Obound）的应用采用了CPU 密集型（CPUbound）的测试标准来评估性能？
接着确认测试结果是否可重复每次重新测试之前要确保系统的状态是一致的如果是非常重要的测试甚至有必要每次测试都重启系统一般情况下需要测试的是经过预热的系统还需要确保预热的时间足够长（请参考前面关于基准测试需要运行多长时间的内容）是否可重复如果预热采用的是随机查询那么测试结果可能就是不可重复的
如果测试的过程会修改数据或者schema那么每次测试前需要利用快照还原数据在表中插入 条记录和插入 万条记录测试结果肯定不会相同数据的碎片度和在磁盘上的分布都可能导致测试是不可重复的一个确保物理磁盘数据的分布尽可能一致的办法是每次都进行快速格式化并进行磁盘分区复制
要注意很多因素包括外部的压力性能分析和监控系统详细的日志记录周期性作业以及其他一些因素都会影响到测试结果一个典型的案例就是测试过程中突然有cron 定时作业启动或者正处于一个巡查读取周期（Patrol Read cycle）抑或RAID卡启动了定时的一致性检查等要确保基准测试运行过程中所需要的资源是专用于测试的如果有其他额外的操作则会消耗网络带宽或者测试基于的是和其他服务器共享的SAN 存储那么得到的结果很可能是不准确的
每次测试中修改的参数应该尽量少如果必须要一次修改多个参数那么可能会丢失一些信息有些参数依赖其他参数这些参数可能无法单独修改有时候甚至都没有意识到这些依赖这给测试带来了复杂性
一般情况下都是通过迭代逐步地修改基准测试的参数而不是每次运行时都做大量的修改举个例子如果要通过调整参数来创造一个特定行为可以通过使用分治法（divideandconquer每次运行时将参数对分减半）来找到正确的值
很多基准测试都是用来做预测系统迁移后的性能的比如从Oracle 迁移到MySQL这种测试通常比较麻烦因为MySQL 执行的查询类型与Oracle 完全不同如果想知道在Oracle 运行得很好的应用迁移到MySQL 以后性能如何通常需要重新设计MySQL 的schema 和查询（在某些情况下比如建立一个跨平台的应用时可能想知道同一条查询是如何在两个平台运行的不过这种情况并不多见）
另外基于MySQL 的默认配置的测试没有什么意义因为默认配置是基于消耗很少内存的极小应用的有时候可以看到一些MySQL 和其他商业数据库产品的对比测试结果很让人尴尬可能就是MySQL 采用了默认配置的缘故让人无语的是这样明显有误的测试结果还容易变成头条新闻
固态存储（SSD 或者PCIE 卡）给基准测试带来了很大的挑战第 章将进一步讨论最后如果测试中出现异常结果不要轻易当作坏数据点而丢弃应该认真研究并找到产生这种结果的原因测试可能会得到有价值的结果或者一个严重的错误抑或基准测试的设计缺陷如果对测试结果不了解就不要轻易公布有一些案例表明异常的测试结果往往都是由于很小的错误导致的最后搞得测试无功而返
返回目录高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
Oracle索引技术
