基准测试是MySQL新手和专家都必须要掌握地一项基本技能。基准测试是针对系统设计的一种压力测试。通常的目标是为了掌握系统的行为。
基准测试的策略
基准测试有两种主要的策略：一是针对整个系统的整体测试，另外是单独测试MySQL。这两种测试也被称为集成式以及单组件式基准测试。针对整个系统做集成式测试而不是单独测试MySQL的原因有以下几点：
测试整个应用程序系统（包括Web服务器，应用程序代码，网络和数据库）非常有用，因为用户不关心MySQL本身的性能，而是应用程序的整体性能。
MySQL并不总是应用程序的瓶颈，这可以通过整体测试来揭示。
只有对整个应用程序进行测试，我们才能发现缓存在各个部分之间的影响。
整个应用程序的集成测试可以揭示应用程序的真实性能，而单个组件的测试则很难做到这一点。
有时，不必了解整个应用程序，而至少在项目的早期阶段，仅需注意MySQL的性能即可。根据以下条件，您可以选择仅测试MySQL
需要比较不同的schema或查询的性能
针对应用中某个具体的测试
为了避免漫长的基准测试，可以通过一个短期的基准测试，做快速的"周期循环"，来检测某些调整后的效果
测试何种指标
考虑以下指标，看看如何满足测试的需求：
吞吐量
吞吐量指的是单位时间内的事务处理数。这一直是经典的数据库应用测试指标。这类基准测试主要针对在线事务处理OLTP的吞吐量，非常适用于多用户的交互式应用。常见的测试单位是每秒事务数，有些也采用每分钟事务数。
响应时间或者延迟
该指示器用于测试任务所需的总时间。根据特定的应用，测试的时间单位可以是微秒，毫秒，秒或分钟。根据不同的时间单位，可以计算平均响应时间，最小响应时间，最大响应时间和百分比。最大响应时间意义不大，因为测试时间越长，最大响应时间就越大。结果通常是不可重复的，并且每个测试可能会获得不同的最大响应时间。因此，通常可以使用百分比响应时间代替最大响应时间。例如，如果95％的响应时间是5毫秒，则意味着可以在95％的时间段内在5毫秒内完成任务。
并发性
并发性是一个非常重要又经常被误解和误用的指标。例如，它经常被表示成多少用户在同一时间浏览一个web站点，经常使用的指标是有多少个会话。然而，HTTP协议是无状态的，大多数用户只是简单地读取浏览器上显式地信息，这并不等于web服务器的并发性。而且web服务器的并发性也不等同于数据库的并发性，而仅仅只表示会话存储机制可以处理多少数据的能力。web服务器的并发性更准确的度量指标，应该是任意时间内有多少同时发生的并发请求。
在应用的不同缓解都可以测量相应的并发性。web服务器的高并发，一般也会导致数据库的高并发，但服务器采用的语言和工具集对此都会有影响。注意不要将创建数据库连接和并发性搞混淆。一个设计良好的应用，同时可以打开成百上千个MySQL数据库服务器连接，但可能同时只有少数连接在执行查询。所以说一个web站点"同时有50000个用户"访问，却可能只有10-15个并发请求到MySQL数据库
换句话说，并发性基准测试需要关注的是正在工作中的并发操作，或者是同时工作中的线程数或者连接数。当并发增加，需要测量吞吐量是否下降，响应时间是否变长，如果是这样，应用可能就无法处理峰值压力。
并发性测试通常不是为了测试应用能达到的并发度，而是为了测试应用在不同并发下的性能。可以通过sysbench指定32、64或者128个线程的测试，然后在测试期间记录MySQL数据库的Threads_running状态值。
可扩展性
当系统的业务压力可能改变时，有必要测试可伸缩性。可伸缩性意味着，如果您将系统的工作量加倍，则在理想情况下可以获得两倍的结果（即吞吐量翻倍）。换句话说，将系统资源增加一倍可以获得两倍的吞吐量。同时，性能必须在可接受的范围内。大多数系统无法实现这种理想的线性扩展。随着压力的变化，吞吐量和性能可能会变差。
可扩展性指标对于容量规范非常有用，它可以提供其他测试无法提供的信息，来帮助发现应用的瓶颈。
归根结底，应该测试那些对用户来说最重要的指标。因此应该尽可能地去收集一些需求，比如，什么样地响应时间是可以接受的，期待多少的并发性，等等。然后基于这些需求来设计基准测试，避免目光短浅地只关注部分指标，而忽略其他指标。