第二章：MySQL基准测试
1.为什么要进行基准测试
基准测试是唯一方便有效的可以观察系统在不同压力下的行为，评估系统的容量的方法
在新系统正式上线到生产环境之前，进行基准测试是个好习惯。切勿相信云RDS提供商或者主机提供商的所为多快多稳定的说法。
基准测试并不是基于真实压力的测试，其压力通常较为单调简单。基准测试在实际情况下通常会要求快速完成，压测实施者往往会施以实际中远远不能达到的且单调请求的压力，虽然有益于测量系统最大性能容量，但往往会使系统或者压测软件崩溃，得不到真正符合实际的数值
真实测试是不可预期且变化多端的，有时情况会复杂且难以解释。
当压测发现新系统可以支持原系统40倍的TPS时，不能简单的就认为新系统可以支持40倍的业务增长。因为系统是个复合的系统，除了单个业务的TPS还要考虑该业务与其他业务或者系统交互之间的交互，甚至网络和磁盘的因素都要考虑到其中。
结论：我们只能进行大概的测试，得出系统的大致余量，基准测试要尽量简单直接，结果之间要容易相互比较，成本低且易于执行。可以使用控制变量法。
2.基准测试的策略
集成式测试：测试整个系统，发现各部分之间缓存带来的影响。整体应用的集成式测试更能揭示应用的真是表现。一般测试组的同事会偏向于使用此策略。
单组件测试：只关注MySQL的性能，进行比较不同的数据库或者查询的性能，针对应用中某个具体问题进行测试，通过一个短期的单组件基准测试，做快速的周期循环，检测某些调整后的效果。
测试目标
有的放矢，测试之前一定要明确测试目的与目标。测试目标决定了选择什么样的测试工具和技术。
吞吐量：单位时间事务处理数，指标为TPS（每秒事务数）。
响应时间：任务所需的整体时间，通常为平均响应时间，最小/最大响应时间。但最大响应时间往往被百分比响应时间代替，例如，若95%的响应时间都是5毫秒，则表示任务在95%的时间段内都可以在5毫秒之内完成。
并发性：Web服务器的并发性是指在任意时间有多少同时发生的并发请求，其高并发一般会导致数据库的高并发。但一个Web站点“同时有5W个用户”访问，却可能只有10-15个并发请求到MySQL数据库。并发性基准测试需要关注的是正在工作中的并发操作，或者同时工作中的线程或者连接数，当并发性增加时，需要关注并测量吞吐量是否随之下降，响应时间变长。并发性测试通常是为了测试在不同并发下的性能。
可扩展性：可以理解为，给系统增加一倍的工作，在理想情况下就能获得两倍的结果，即吞吐量增加一倍。或者说给系统增加一倍的资源就能获得两倍的吞吐量。可扩展性指标可以帮助发现应用性能的平静。
总结：确定测试对象为对于用户来说最重要的指标，然后收集应用方的需求，例如：什么样的响应时间是可以接受的，期待多少的并发性等等，最后基于这些需求进行设计基准测试。
测试方法
测试时应避免如下的常见错误：
使用部分的真实数据进行测试和扩展性有关的项目。
错误的数据分布
测试数据相对生产数据而言分布不均匀
在多用户的场景中，却只测试单用户的情景。
在单台服务器上测试分布式应用
测试脚本或者软件模拟的用户行为不真实，不现实
短时间内反复执行同一个查询，会因为查询缓存的存在导致结果不准确
在一轮结果异常的测试结束后不分析异常的原因就直接进入下一轮
不进行预热就直接进行测试
未使用合理的数据库参数
测试时间太短
设计和规划基准测试
第一步先提出问题并明确目标，然后觉得采用标准的基准测试还是设计特定情景的测试
基准测试软件：TPCH,即席查询和决策支持型应用的基准测试。即OLAP
TPCC,订单型业务交易系统应用的基准测试。即OLTP
LinkBench，人际关系型应用的基准测试。等等
特定情境测试：首先获得生产数据集的快照
然后只针对数据进行查询。
提前做好测试规划：应包括准备测试数据，系统配置的步骤，设计预热方案，测量并分析测试结果
基准测试应运行足够长的时间
大部分系统都会有一些应对突发情况的余量，能够收集性能尖峰，将一些工作延迟到高峰期之后执行，但当对机器加压足够长的时间后，这些余量会被消耗殆尽，系统的短期高峰也就无法维持原来的高性能。至少应当让测试一直运行到确认系统已经稳定运行之后。其中，系统看起来稳定的时间至少大于等于系统预热所需要的时间。
如果没有时间去完成准确完整的基准测试，那么已经花费的所有时间都是一种浪费。
获取系统性能和状态
执行基准测试时，需要尽可能多的收集被测试系统的信息，最好为测试建立一个专用的目录，每次执行一轮测试都创建对应的独立子目录，将测试结果，配置文件，测试指标，脚本和其他相关说明都保存在其中。
需要着重考虑的系统状态和指标：CPU使用率，磁盘IO，网络流量统计，数据库status杂项等。
下面给出一个数据收集脚本范例：
#!/bin/sh
INTERVAL=5
PREFIX=$INTERVAL-sec-status
RUNFILE=/root/running
mysql -e 'show global variables'>>mysql-variables
while test -e $RUNFILE; do
file=$(date +%F_%H)
sleep=$(date +%s.%N |awk "{print $INTERVAL -(\$1 % $INTERVAL)}")
sleep $sleep
ts="$(date +"TS %s.%N %F %T")"
loadavg="$(uptime)"
echo "$ts $loadavg">> $PREFIX-${file}-status
mysql -e "show global status" >> $PREFIX-${file}-status &
echo "$ts $loadavg">> $PREFIX-${file}-innodbstatus
mysql -e "show engine innodb status\G" >> $PREFIX-${file}-innodbstatus &
echo "$ts $loadavg">> $PREFIX-${file}-processlist
mysql -e "show full processlist\G" >>$PREFIX-${file}-processlist &
echo $ts
done
echo Exiting because $RUNFILE not exist
获取准确的测试结果
第一步：审查如下项目
是否选择了正确的基准测试类型？
是否为问题收集了相关的线上数据？
是否采用了正确的测试标准？
第二步：确认测试结果是否有可重复性。每次重新测试之前都要确保系统的状态是一致的，甚至每次测试之前都重启系统。还要确保每次预热的时间足够长。
如果预热测试用的是随机查询，那么测试结果可能就不是可重复的。如果测试的过程中会修改数据或者DDL，那么每次测试之前，需要利用快照还原数据。
可以利用控制变量法，每次测试中，修改的参数应该尽量少。一般情况下，都是通过迭代逐步地修改基准测试的参数。
如果在测试中出现异常结果，不要轻易当作垃圾结果直接丢弃，应当认真研究并找到产生这种结果的原因。如果对测试结果不了解，就不要轻易公布。
运行测试并分析结果
基准测试通常需要运行多次，具体运行多少次要看对结果的计分方式，以及测试结果的重要程度。若需要提高测试的准确度就需要多运行几次。一般在测试的实践中，可以取最好的结果值，或者所有结果的平均值，抑或是从五个测试结果里去最好三个值的平均值。只要测试的结果能满足目前的需求，简单地运行几轮测试，看看结果的变化就可以了。若结果变动很大，可以再多运行几次，或者运行更长的时间，以求获得更确定的结果。
在运行完测试，获得测试结果后，要把测试结果的数字，通过分析变成知识或者经验，并回答在设计测试时提出的问题或者目标。可以通过编写脚本来抽象分析测试结果中的数据。这里给出一个针对前面采集脚本的一个分析脚本。
#!/bin/sh
awk '
BEGIN{
printf "#ts date time load QPS";
fmt = " %.2f";
}
/^TS/ { # The timestamp lines begin with TS.
ts = substr($2, 1, index($2,".") - 1);
load = NF - 2;
diff = ts -prev_ts;
prev_ts = ts;
printf "\n%s %s %s %s",ts,$3,$4,substr($load, 1, length($load)-1);
}
/Queries/ {
printf fmt, ($2-Queries)/diff;
Queries=$2
}
' "$@"
运行方式：sh hi_anaylyze.sh 5-sec-status-2018-02-22_14_status >>4plot.log （将分析后的结果记入4plot.log中）
绘图
绘图有很多种方式，EXCEL,rrdtools,gnuplot都可以。
这里介绍gnuplot的绘图方式。
gunplot>plot '4plot' using 5 with lines title 'QPS', 4 with lines title 'load'
解析：using 5 表示使用第5列数据作图
with lines 定义图中的趋势使用线来表示
title 'QPS' 定义线的名称
使用,（逗号）分割，进行多列数据的绘制
如图：
测试工具
常用集成式测试工具：
ab
http_load
Jmeter
常用单组件测试工具：
mysqlslap：包含在MySQL的安装包中
sql-bench：包含在MySQL的安装包中（5.6及以前）
TPCC,percona`s TPCC：针对订单交易型
sysbench：全能的多线程系统压测工具，可以配合Lua脚本进行多样化的系统软硬件测试。
3.压力测试测试实操
本文转自 angry_frog 51CTO博客，原文链接:http://blog.51cto.com/l0vesql/2067059
