关键字：数据库运维服务、数据库运维管理、数据库灾备

问题

用 mysqlslap 压测 SQL 的结果，好像比用 sysbench 压测 SQL 的结果更平稳，为什么？

实验

随便找个数据库，

我们用以下 SQL 进行压测：

select sleep(@val := coalesce(@val, 0) + 1) from dual;

在同一个数据库连接中，这个 SQL 每运行一次，sleep 的时间都会加一秒。第一次是 sleep(1)，第二次是 sleep(2)，...

我们先用 mysqlslap 进行压测：

查看结果：

解读一下 mysqlslap 的结果：

• 每轮 SQL 平均运行 15s

• 一轮 SQL 平均运行 5 个 SQL

• 推导出每个 SQL 平均运行 3s

需要注意：结果中有个 Max 和 Min，经常发现大家将 Max 除以每轮 SQL 的个数，得出 SQL 延迟的最大时间，这个计算是错误的。

Max 和 Min 指的是如果 mysqlslap 进行多轮测试（iterations > 1），每轮运行时间的最大值和最小值。与单个 SQL 的延迟无关。

在本例中，如果我们将 --iterations 改成 3，得到的 Max/Avg/Min 都是 15s 左右，但我们知道这些 SQL 的延迟分别是 1s,2s,...,5s，通过 Max/Avg/Min 无法计算得到单个 SQL 延迟的最大值/最小值。

再用 sysbench 测一次：

写一个 LUA 脚本（不会写的同学，可以直接复制 sysbench 自带的脚本 bulk_insert.lua，拿过来改一改）：

然后运行 sysbench 压测：

查看结果，会发现 95% 分位数偏离平均值比较远，意味着同一个 SQL 的延迟变化较大。

通过以上简单实验，我们发现：

• sysbench 可以反映出单个 SQL 或者局部 SQL 延迟异常的情况

• mysqlslap 的测量对象是一个轮次，不能反映单个 SQL 的延迟情况。如果用简单的除法估算 SQL 延迟，SQL 延迟的波动会比实际情况平稳得多。

也就是说 mysqlslap 比 sysbench 的压测结果更平稳的原因，是大家对 mysqlslap 的结果进行处理时进行了错误的计算，导致波动被消除。

小贴士

本例中，我们特意使用了同一个 SQL。如果业务压力来自于不同的 SQL，可以使用 ps_statement_avg_latency_histogram 获取不同 SQL 间的延迟差异图。

关键字：数据库运维服务、数据库运维管理、数据库灾备