主题：MySQL基准测试的相关内容及可用的工具。

• 什么是基准测试
• 为什么要做基准测试
• MySQL基准测试中要注意的问题
• 基准测试方案
• MySQL基准测试工具及使用方法

什么是基准测试

benchmark：基准，参照; 标准检查程序; 水准标。

在计算中，基准是运行计算机程序、一组程序或其他操作的行为，以便通过对其进行一些标准测试和试验来评估对象的相对性能。 “基准”一词也主要用于精心设计的基准程序本身。

基准测试通常与评估计算机硬件的性能特征相关联，例如CPU的浮点运算性能。但是有些技术也适用于软件。例如，针对编译器或数据库管理系统，来运行软件基准测试。

基准测试提供了一种比较不同子系统在不同芯片/系统架构上的性能的方法。

测试套件是一种旨在评估软件正确性的系统。

为什么要做基准测试

基准测试用于模拟组件或系统上特定类型的工作负载。基准测试可以解决一下问题，或者更多：

• 掌握系统：掌握系统的行为，在某些压力下系统会有什么表现。
• 问题重现：重现系统中的某些问题，从而可以解决这些问题。
• 发现瓶颈：模拟高负载，可以找出系统瓶颈所在。
• 新环境性能：新硬件的可靠性测试，测试系统在新的环境中的表现。
• 规划业务：评估系统能支持的业务能力。评估所需要加入的硬件容量、带宽等。
• 环境适应能力：测试出系统对不同数据分布情况的处理，或者随机并发下的表现。
• 证明：某个优化操作是否真的有效。硬件的升级、系统的升级或者软件的升级是否达到了预期的效果。

MySQL基准测试中要注意的问题

基准测试并不是那么容易就完成的，通常要进行若干轮的迭代，才能达到精准和有用。而且解释基准测试的数据也是比较复杂的。有如下的问题：

• 基准测试并不是真实的压力测试，基准测试的压力相对比较简单。但是，基准测试却可以针对某个问题进行分析，而压力测试中的变化因素过多，不利于问题分析。
• 基准测试要求尽快的完成，所以为了完成基准测试，我们会在给系统非常大的压力。
• 基准测试工具也会影响到准确性。
• 不能根据基准测试的结果做简单的推断。基准测试只是针对某个点进行了评估，但是随着系统的增长，系统的各个方面都在增长，所以不能根据某个基准测试结果做简单的推断。
• 基准测试要简单直接，以处理问题为主。再说一次：基准测试不是压力测试，基准测试只是为了发现某一个点。
• 数据集：为了结果能够尽可能的准确，测试所用的数据集应该尽可能的接近真实的数据集，如果可以，应该采用生产环境的数据快照。

基准测试方案

集成式(full-stack)

对整个系统进行测试。之所以要对整个系统做基准测试，有一下几点原因：

• 从整体来讲，MySQL只是整个应用的一部分，整体的性能才应该是关注的重点。
• MySQL有时并不是性能的瓶颈，性能的瓶颈也可能出现在应用其他部分。
• 只有整体测试，才能发现各个部分之间缓存带来的影响。
• 整体性测试才能反映整个应用的性能，单组件测试是做不到这一点的。

整体测试的潜在问题：

• 应用整体的基准测试很难建立，甚至很难正确设置。
• 由此引发的问题就是无法正确的反映问题，从而导致了无法作出正确的决定。

单组件式(single-component)

对MySQL进行测试。有时候并不需要了解整个系统的性能，只需要对MySQL进行单独测试：

• 比较不同schema或者查询的性能。
• 针对应用中的某个MySQL相关问题进行测试。

测试何种指标

即要测试哪一方面。测试目标不同，则使用的方法、技术及工具都不相同。可测试的指标如下：

• 吞吐量
• 响应时间或者延迟
• 并发性
• 可扩展性

测试的指标必须是对与用户或者系统非常重要的指标。然后按照期望中的性能(并发量、响应时间)，针对这些指标展开测试。不能盲目的测试，而忽略其他的指标。

MySQL基准测试方法

基准测试中常见的错误

• 数据集不相称：测试使用的数据集是真是情况的子集，很显然这样是测试不出问题的。
• 数据分布不相称：测试使用的数据分布与真是情况不匹配。
• 环境不匹配：测试环境与真实环境不匹配。比如：多用户对单用户、单服务器对分布式应用。
• 用户行为：测试模拟的用户行为与实际的用户行为不匹配。
• 单一：反复执行某一个操作，实际中的操作是不尽相同的。单一查询会导致缓存命中率很高。
• 忽略错误：当测试完成之后，首先要检查是否有错误产生。
• 忽略系统预热：不能在系统重启之后马上测试。比如：系统重启之后，还没有任何缓存。
• 使用默认配置
• 测试时间过短。

设计和规划基准测试(基准测试的方案)

标准的基准测试

专门设计的基准测试
专门设计的基准测试方案，需要一个迭代的过程。下面是要注意的一些问题：

1. 首先要获得生产库中的数据快照，用于测试。
2. 获取真实环境中的查询。为了获取准确的结果，应该采用生产服务器的一天的查询，或者比较有代表性的时间段。
3. 记录不同级别的查询。如果是集成测试，可以记录HTTP请求，也可以打开MySQL的查询日志。然后在多线程环境下，重复执行这些查询。
4. 写下详细的测试规划。
5. 详细的记录测试结果，有助于数据的分析。

获取系统的性能和状态
执行基准测试的时候要尽可能多的收集系统信息。将相关的测试结果、配置文件、测试指标、脚本、相关的说明都保存起来。数据没有多余的。要收集的数据包括：IO、CPU、网络、SHOW GLOBAL STATUS计数器等。

获取准确的测试结果
如何保证基准测试的结果是准确的：

• 基准测试的选择是否正确？首否收集了相关的数据？是否采用了错误的测试标准？
• 每次测试中，系统的状态是否是相同的。比如：是否每次都进行了预热？数据集是否相同？数据的分布是否相同？
• 每次修改的参数应该尽可能的少。修改过多的参数，会给参照带来复杂性。一般情况下，都是通过迭代来逐步的修改参数。

运行基准测试

基准测试的运行时长
基准测试要运行足够长的时间。

如果要测试系统在稳定状态时的性能，当然要等系统稳定之后再进行测试和观察。

有时可能无法确定要运行多长时间，那么可以让测试一直运行，然后观察确认系统稳定。

如果运行时间过短，是无法得出正确结论的。

运行次数
基准测试的运行尽量脚本化。因为基准测试中有众多的步骤要，自动化可以减少遗漏，也避免了繁琐的操作。同时也有助于数据的整理。

基准测试一般需要运行多轮，直到得到确定的结果。

分析结果

脚本分析
得到结果之后，可以对数据展开分析了。可以使用sed或者awk写一些简单的脚本来分析数据。

用绘图分析结果
你可以使用gnuplot或者R绘图来显示数据。有些时候数据并不能直观的反映现象，而统计图却可以直观的反映问题。

MySQL基准测试工具及使用方法

mysqlslap
关于mysqlslap的使用方法查看另外一篇文章：《mysqlslap》

sysbench
sysbench的使用查看官方文档：https://github.com/akopytov/sysbench

MySQL Benchmark Suite (sql-bench)

Super Smack

Database Test Suite

Percona’s TPCC-MySQL Tool

dbt2

MySQL BENCHMAEK()

参考文献

《高性能MySQL》