有两个主要的基准测试策略：可以把对一个整体的应用做基准测试，或者就是对单独的MySQL做基准测试。这两种一般被成为“全栈式full-stack”和“单独组件single-component”的基准测试。对整个应用的基准测试好于单独的对MySQL。原因如下：

　　* 你测试整个应用，包括了web服务器，程序代码，数据库。你不用单独的考虑MySQL的性能。你关心的是整个应用。

　　* MySQL并不总是应用的瓶颈。全栈的基准测试可以发现瓶颈。

　　* 只有全栈的测试，才能看出来每部分的缓存的行为。

　　* 基准测试能反映出应用实际的表现，但是当你测试一部分就很难做到了。

　　换句话说，基于应用的基准测试可能会非常难创建以及甚至更难去正确的准备。如果基准设计的很烂，你可能会做错误的决定。因为结果本身就不是真实的。

　　有的时候，你可能不需要了解整个应用。至少在最初阶段，你可能仅仅需要MySQL的基准测试。在下列的条件下，这种基准测试比较有用：

　　* 你要比较不同的数据模型或语句。

　　* 在应用中，你想针对某个问题做基准测试。

　　* 你要避免长期的基准测试，用短期的基准测试来使你短期内快速更该和估算一些修改。

　　当你重复使用应用程序的应用于真实的数据，对于MySQL的基准测试也非常有用。数据本身和数据集的大小需要是真实的。如果可能，请使用真实数据的拷贝。

　　不幸的是，设置真实的基准测试可能有些复杂和消耗时间。如果你得到了产品数据集的拷贝，你应该感到幸运……当然，这还是有可能的。如，你可能开发一个很少用户量和数据的应用。如果你想知道随着数据的增长，这个应用的表现如何，你可能没有什么选择，但是可以模拟大量的应用数据和负荷。

　　测量些什么？

　　你在开始基准测试之前，需要知道你的目标-其实是在你设计基准测试之前。你的目标要决定使用哪种工具和技术能使你获得准确的有意义的结果。用问题来构建你的目标，如“这个CPU好于那一个么？”或者“这个新的索引好于当前的那个么？”

　　这可能不是显而易见的，但是你有的时候需要不同的方法测量不同的指标。如，延迟和吞吐量可能需要不同的基准测试。

　　考虑下面的一些测量以及它们怎样适用于你的性能目标。

　　每单位时间内的事物处理次数（Transactions per time unit）

　　对于数据库应用的基准测试，它总是经典之一。标准的基准测试如TPC-C广泛引用它们，以及许多数据库厂商都致力于让它们工作的更好。这些基准测试测量了事物处理（OLTP）性能以及最适合的多用户交互程序。这个测量单位通常是没秒的事物处理次数（transactions per second）。