MySQL基准测试
基准测试的作用
验证基于系统的一些假设。
重现系统中的某些异常行为。
测试系统当前的运行情况。
如果不清楚系统当前的性能，就无法确认某些优化的效果如何。也可以利用历史的基准测试结果来分析诊断一些无法预测的问题。
模拟比当前系统更高的负载。
规划未来的业务增长。
基准测试可以评估在项目未来的负载下，需要什么样的硬件，需要多大容量的网络，以及其他相关资源。这有助于降低系统升级和重大变更的风险。
测试应用适应可变环境的能力。
例如，通过基准测试，可以发现系统在随机的并发峰值下的性能表现，或者是不同配置的服务器之间的性能表现。基准测试也可以测试系统对不同数据分布的处理能力。
测试不同的硬件、软件和操作系统配置。
比如RAID 5还是RAID 10更适合当前的系统？如果系统从ATA硬盘升级到SAN存储，对于随机写性能有什么帮助？Linux 2.4系列的内核会比2.6系列的可扩展性更好吗？升级MySQL的版本能改善性能吗？为当前的数据采用不同的存储引擎会有什么效果？所有这类问题都可以通过专门的基准测试来获得答案。
证明新采购的设备是否配置正确。
通过基准测试来对新系统进行压测，可以发现了很多错误的配置，以及硬件组件的失效等问题。因此在新系统正式上线到生产环境之前进行基准测试是一个好习惯，永远不要相信主机提供商或者硬件供应商的所谓系统已经安装好，并且能运行多快的说法。如果可能，执行实际的基准测试永远是一个好主意。
基准测试的策略
针对整个系统的整体测试
测试整个应用系统，包括Web服务器、应用代码、网络和数据库是非常有用的，因为用户关注的并不仅仅是MySQL本身的性能，而是应用整体的性能。
MySQL并非总是应用的瓶颈，通过整体的测试可以揭示这一点。
只有对应用做整体测试，才能发现各部分之间的缓存带来的影响。
整体应用的集成式测试更能揭示应用的真实表现，而单独组件的测试很难做到这一点。
只测试MySQL
需要比较不同的schema或查询的性能。
针对应用中某个具体问题的测试。
为了避免漫长的基准测试，可以通过一个短期的基准测试，做快速的“周期循环”，来检测出某些调整后的效果。
测试何种指标
吞吐量
吞吐量指的是单位时间内的事务处理数。这一直是经典的数据库应用测试指标。常用的测试单位是每秒事务数（TPS），有些也采用每分钟事务数（TPM）。
响应时间或者延迟
这个指标用于测试任务所需的整体时间。根据具体的应用，测试的时间单位可能是微秒、毫秒、秒或者分钟。使用图表有助于理解测试结果。可以将测试结果绘制成折线图（比如平均值折线或者95％百分比折线）或者散点图，直观地表现数据结果集的分布情况。
并发性
并发性的测量完全不同于响应时间和吞吐量。它不像是一个结果，而更像是设置基准测试的一种属性。并发性测试通常不是为了测试应用能达到的并发度，而是为了测试应用在不同并发下的性能。
可扩展性
简单地说，可扩展性指的是，给系统增加一倍的工作，在理想情况下就能获得两倍的结果（即吞吐量增加一倍）。或者说，给系统增加一倍的资源（比如两倍的CPU数），就可以获得两倍的吞吐量。
基准测试方法
设计和规划基准测试
规划基准测试的第一步是提出问题并明确目标。然后决定是采用标准的基准测试，还是设计专用的测试。
然后，针对数据运行查询。可以建立一个单元测试集作为初步的测试，并运行多遍。
建立将参数和结果文档化的规范，每一轮测试都必须进行详细记录。文档规范可以很简单，比如采用电子表格（spreadsheet）或者记事本形式，也可以是复杂的自定义的数据库。需要记住的是，经常要写一些脚本来分析测试结果，因此如果能够不用打开电子表格或者文本文件等额外操作，当然是更好的。
基准测试应该运行多长时间
基准测试应该运行足够长的时间，这一点很重要。有时候无法确认测试需要运行多长的时间才足够，可以让测试一直运行，持续观察直到确认系统已经稳定。下图是系统磁盘读和写吞吐量的时序图。
获取系统性能和状态
在执行基准测试时，需要尽可能多地收集被测试系统的信息。
基准测试工具
http_load
MySQL基准测试套件
sysbench