2、基准测试的策略

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

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

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

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

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

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

　　另外一方面，应用的整体基准测试很难建立，甚至很难正确设置。如果基准测试的设计有问题，那么结果就无法反映真实的情况，从而基于此做的决策也就可能是错误的。

　　不过，有时候不需要了解整个应用的情况，而只需要关注MySQL 的性能，至少在项目初期可以这样做。基于以下情况，可以选择只测试MySQL ：

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

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

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

　　另外，如果能够在真实的数据集上执行重复的查询，那么针对MySQL 的基准测试也是有用的，但是数据本身和数据集的大小都应该是真实的。如果可能，可以采用生产环境的数据快照。

　　不幸的是，设置一个基于真实数据的基准测试复杂而且耗时。如果能得到一份生产数据集的拷贝，当然很幸运，但这通常不太可能。比如要测试的是一个刚开发的新应用，它只有很少的用户和数据。如果想测试该应用在规模扩张到很大以后的性能表现，就只能通过模拟大量的数据和压力来进行。

　　2.1 测试何种指标

　　在开始执行甚至是在设计基准测试之前，需要先明确测试的目标。测试目标决定了选择什么样的测试工具和技术，以获得精确而有意义的测试结果。可以将测试目标细化为一系列的问题，比如，“这种CPU 是否比另外一种要快？”，或“新索引是否比当前索引性能更好？”

　　有时候需要用不同的方法测试不同的指标。比如， 针对延迟（latency） 和吞吐量（throughput）就需要采用不同的测试方法。

　　请考虑以下指标，看看如何满足测试的需求。

　　吞吐量

　　吞吐量指的是单位时间内的事务处理数。这一直是经典的数据库应用测试指标。一些标准的基准测试被广泛地引用，如TPC-C（参考http://www.tpc.org），而且很多数据库厂商都努力争取在这些测试中取得好成绩。这类基准测试主要针对在线事务处理（OLTP）的吞吐量，非常适用于多用户的交互式应用。常用的测试单位是每秒事务数（TPS），有些也采用每分钟事务数（TPM）。

　　响应时间或者延迟

　　这个指标用于测试任务所需的整体时间。根据具体的应用，测试的时间单位可能是微秒、毫秒、秒或者分钟。根据不同的时间单位可以计算出平均响应时间、最小响应时间、最大响应时间和所占百分比。最大响应时间通常意义不大，因为测试时间越长，最大响应时间也可能越大。而且其结果通常不可重复，每次测试都可能得到不同的最大响应时间。因此，通常可以使用百分比响应时间（percentile responsetime）来替代最大响应时间。例如，如果95% 的响应时间都是5 毫秒，则表示任务在95% 的时间段内都可以在5 毫秒之内完成。

　　使用图表有助于理解测试结果。可以将测试结果绘制成折线图（比如平均值折线或者95% 百分比折线）或者散点图，直观地表现数据结果集的分布情况。通过这些图可以发现长时间测试的趋势。本章后面将更详细地讨论这一点。