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