MySQL基准测试
2.1 基准测试的策略
基准测试有两种主要的策略：一是针对整个系统的整体测试，另外是单独测试MySQL。
2.1.1 测试何种指标
吞吐量
吞吐量是指单位时间内的事务处理数。常用的测试单位是每秒事务数（TPS），有些也采用每分钟事务数（TPM）。
响应时间或者延迟
这个指标用于测试任务所需的整体时间。根据具体的应用，测试的时间单位可能是微妙、毫秒、秒或者分钟。根据不同的时间单位可以计算出平均响应时间、最小响应时间、最大响应时间和所占百分比。
并发性
WEB服务器的并发性不等于数据库的并发性。所以，并发性基准测试需要关注的是正在工作中的并发操作，或者是同时工作中的线程数或者连接数。当并发性增加时，需要测量吞吐量是否下降，响应时间是否变长，如果是这样，应用可能就无法处理峰值压力。
可以通过sysbench指定32、64或者128个线程的测试，然后在测试期间记录MySQL数据库的Threads_running状态值。
可扩展性
可扩展性指的是，给系统增加一倍的工作，在理想情况下就能获得两倍的结果（即吞吐量增加一倍）。或者说，给系统增肌一倍的资源（比如两倍的CPU数），就可以获得两倍的吞吐量）。或者说，给系统增加一倍的资源（比如两倍的CPU数），就可以获得两倍的吞吐量。
2.1.2 基准测试的方法
以下测试可能导致测试结果无用或者不精确：
1. 使用真实数据的子集而不是全集。例如应用需要处理几百GB的数据，但测试只有1GB数据；或者只使用当前数据进行测试，却希望模拟未来业务大幅度增长后的情况。
2. 使用错误的数据分布。例如使用均匀分布的数据测试，而系统的真实数据有很多热点区域（随机生成的测试数据通常无法模拟真实的数据分布）。
3. 使用不真实的分布参数。例如假定所有用户的个人信息都会被平均读取。
4. 在多用户场景中，只做单用户测试。
5. 在单服务器上测试分布式应用。
6. 与真实用户行为不匹配。
7. 反复执行同一个查询。
8. 没有检查错误。
9. 忽略了系统预热的过程。
10. 使用默认的服务器配置。
11. 测试时间太短。