第二章 MySQL基准测试

基准测试是针对系统设计的一种压力测试。通常的目标是为了掌握系统的行为。重新某个系统状态，或者是做新硬件的可靠性测试。

2.1 为什么需要基准测试

基准测试是唯一方便有效的、可以学习系统在给定的工作负载下会发生什么的方法。可以观察系统在不同压力下的行为，评估系统的容量，掌握哪些是重要的变化，或者观察系统如何处理不同的数据。

1.验证基于系统的一些假设，确认这些假设是否符合实际情况。

2.重现系统中的某些异常行为，以解决这些异常。

3.测试系统当前的运行情况。如果不清楚系统当前的性能，就无法确认某些优化的效果如何。

4.模拟比当前系统更高的负载，以找出系统随着压力增加而可能遇到的拓展性平静下来。

5.规划未来的业务增长。基准测试可以评估在项目未来的负载下，需要什么样的硬件，多大容量的网络，以及其他相关资源。

6.测试应用适应可变环境的能力。也可测试系统对数据分布的处理能力。

7.测试不同的硬件、软件和操作系统配置。

8.证明新采购的设备是否配置正确。

基准测试的一个主要问题在于其不是真实压力的测试。基准测试的压力会受到比如数据量、数据和查询的分布等因素影响。但最重要的一点还是基准测试通常要求尽可能快的执行完毕，所以经常给系统造成过大的压力。

2.2 基准测试的策略

基准测试有两种主要的策略：一种是针对整个系统的整体测试，另外是单独测试MySQL。两种测试也被称为集成式以及单组件式集成测试。

针对整个系统做集成式测试，而不是单独测试MySQL的原因有以下几点：

• 测试整个应用系统，包括Web服务器、应用代码、网络和数据库是否非常有用的，因为用户关注的并不仅仅是MySQL本身的性能，而是应用整体的性能。

• MySQL并非总是应用的瓶颈，通过整体测试可以揭露这一点。

• 只有对应用做整体测试，才能发现各个部分之间的缓存带来的影响。

• 整体应用的集成式测试更能揭示应用的真实表现，而单独组建的测试很难做到这一点。

但是，应用的整体基准测试很难建立，而且很难正确设置。

不过，有时候不需要了解整个应用的情况，而只需要关注MySQL的性能。基于以下情况，可以只选择测试MySQL：

• 需要比较不同的schema或者查询性能。

• 针对应用中的某个问题的测试。

• 为了避免漫长的基准测试，可以通过一个短期的基准测试，做快速的“周期循环”，来检测出某些调整后的效果。

2.1.1 测试何种指标

在开始执行甚至在设计基准测试之前，需要先明确测试的目标。不同的方法测试不同的指标。

吞吐量

吞吐量指的是单位时间内的事务处理数。

响应时间或者延迟

指的是测试任务所需的整体时间。测试的时间单位可能是微妙、毫秒、秒或者分钟。根据不同的时间单位可以计算出响应时间、最小响应时间、最大响应时间和所占百分比。使用图表有助于理解测试结果。

并发性

并发行并非同时访问统一站点用户的数量，而关注的是工作中的并发操作，或者是同时工作中的线程数或者连接数。

可拓展性

简单的说，可拓展性指的是，给系统增加一倍多工作，在理想情况下就能获得两倍的结果。或者说给系统增加一倍的资源，就可以获得两倍的吞吐量。

2.3 基准测试方法

在基准测试之前，先来看一下如何避免一些常见的错误，这些错误可能会导致测试结果无用或者不准确：

• 使用真是数据的子集而不是全集。

• 使用错误的数据分布。

• 使用不真实的分布参数。

• 再多用户场景下，只做单用户的测试。

• 在单服务器上测试分布式应用。

• 与真实用户行为不匹配。

• 反复执行同一个查询。

• 没有检查错误。基准测试完成后，一定要检查一下错误日志，这应当是基本的要求。

• 忽略了系统预热的过程。

• 使用默认的服务器配置。

• 测试时间太短。

2.3.1 设计和规划基准测试

规划基准测试的第一步是提出问题并明确目标。然后决定采用标准的基准测试，还是选择专用的测试。

如果采用标准的基准测试，应该确定选择了合适的测试方案。

2.3.2 基准测试应该运行多久时间

基准测试应该运行足够长的时间，这一点很重要，如果需要测试系统在稳定状态时的性能，那么当然需要在稳定状态下的测试并观。大部分系统都会有一些应对突发情况的余量能够吸收性能尖峰，将一些工作延迟到高峰期之后执行。但当对机器加压足够长时间之后，这些余量会被耗尽，系统的短期尖峰也就无法维持原来的高性能。如果无法确认测试需要多长时间才足够，那就可以让测试一直执行。

2.3.3 获得系统性能和状态