高性能MySQL：运行基准测试并分析结果
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了高性能MySQL：运行基准测试并分析结果相关的知识，希望对你有一定的参考价值。
参考技术A运行基准测试并分析结果
一旦准备就绪 就可以着手基准测试 收集和分析数据了
通常来说 自动化基准测试是个好主意 这样做可以获得更精确的测试结果 因为自动化的过程可以防止测试人员偶尔遗漏某些步骤 或者误操作 另外也有助于归档整个测试过程
自动化的方式有很多 可以是一个Makefile 文件或者一组脚本 脚本语言可以根据需要选择 shell PHP Perl 等都可以 要尽可能地使所有测试过程都自动化 包括装载数据 系统预热 执行测试 记录结果等
一旦设置了正确的自动化操作 基准测试将成为一步式操作 如果只是针对某些应用做一次性的快速验证测试 可能就没必要做自动化 但只要未来可能会引用到测试结果 建议都尽量地自动化 否则到时候可能就搞不清楚是如何获得这个结果的 也不记得采用了什么参数 这样就很难再通过测试重现结果了
基准测试通常需要运行多次 具体需要运行多少次要看对结果的记分方式 以及测试的重要程度 要提高测试的准确度 就需要多运行几次 一般在测试的实践中 可以取最好的结果值 或者所有结果的平均值 亦或从五个测试结果里取最好三个值的平均值 可以根据需要更进一步精确化测试结果 还可以对结果使用统计方法 确定置信区间（confidence interval）等 不过通常来说 不会用到这种程度的确定性结果注 只要测试的结果能满足目前的需求 简单地运行几轮测试 看看结果的变化就可以了 如果结果变化很大 可以再多运行几次 或者运行更长的时间 这样都可以获得更确定的结果
获得测试结果后 还需要对结果进行分析 也就是说 要把 数字 变成 知识 最终的目的是回答在设计测试时的问题 理想情况下 可以获得诸如 升级到 核CPU 可以在保持响应时间不变的情况下获得超过 % 的吞吐量增长 或者 增加索引可以使查询更快 的结论 如果需要更加科学化 建议在测试前读读null hypothesis 一书 但大部分情况下不会要求做这么严格的基准测试
如何从数据中抽象出有意义的结果 依赖于如何收集数据 通常需要写一些脚本来分析数据 这不仅能减轻分析的工作量 而且和自动化基准测试一样可以重复运行 并易于文档化 下面是一个非常简单的shell 脚本 演示了如何从前面的数据采集脚本采集到的数据中抽取时间维度信息 脚本的输入参数是采集到的数据文件的名字
假设该脚本名为 *** yze 当前面的脚本生成状态文件以后 就可以运行该脚本 可能会得到如下的结果
第一行是列的名字 第二行的数据应该忽略 因为这是测试实际启动前的数据 接下来的行包含Unix 时间戳 日期 时间（注意时间数据是每 秒更新一次 前面脚本说明时曾提过） 系统负载 数据库的QPS（每秒查询次数）五列 这应该是用于分析系统性能的最少数据需求了 接下来将演示如何根据这些数据快速地绘成图形 并分析基准测试过程中发生了什么
返回目录 高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
lishixinzhi/Article/program/MySQL/201311/29735
MySQL基准测试工具：sysbench 新手入门体验
文章目录
安装 sysbench
最初接触这个工具还是在两年前看《高性能MySQL》的时候，那时候没安装上呀，就没弄了、
我就想起来现在 luasql 也没安装上，会不会过段时间这也不是事儿了。
1、wget https://github.com/akopytov/sysbench/archive/1.0.20.tar.gz
2、tar -zxvf 1.0.20.tar.gz
3、
sudo apt install -y automake
sudo apt install -y libtool
sudo apt install -y pkg-config
sudo apt install -y libmysqlclient-dev
4、cd cd sysbench-1.0.20/
5、./autogen.sh
6、./configure
7、sudo make -j
8、sudo make install
9、sysbench --version
sysbench语法
sysbench的基本语法如下：
sysbench [options]... [testname] [command]
command：sysbench要执行的命令，包括：
prepare：为测试提前准备数据
run：执行正式的测试
cleanup：在测试完成后对数据库进行清理
在新版本中，–test参数已经声明为废弃，可以不使用–test，而是直接指定脚本。
sysbench ./tests/include/oltp_legacy/oltp.lua
测试时使用的脚本为lua脚本，可以使用sysbench自带脚本，也可以自己开发。对于大多数应用，使用sysbench自带的脚本就足够了。
sysbench的options参数有很多，其中比较常用的包括：
MySQL连接信息参数
--mysql-host：MySQL服务器主机名，默认localhost；如果在本机上使用localhost报错，提示无法连接MySQL服务器，改成本机的IP地址应该就可以了。
--mysql-port：MySQL服务器端口，默认3306
--mysql-user：用户名
--mysql-password：密码
MySQL执行参数
--oltp-test-mode：执行模式，包括simple、nontrx和complex，默认是complex。simple模式下只测试简单的查询；nontrx不仅测试查询，还测试插入更新等，但是不使用事务；complex模式下测试最全面，会测试增删改查，而且会使用事务。可以根据自己的需要选择测试模式。
--oltp-tables-count：测试的表数量，根据实际情况选择
--oltp-table-size：测试的表的大小，根据实际情况选择
--threads：客户端的并发连接数
--time：测试执行的时间，单位是秒，该值不要太短，可以选择120
--report-interval：生成报告的时间间隔，单位是秒，如10
使用示例
准备数据：
sysbench ./tests/include/oltp_legacy/oltp.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=123456 --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=100000 --threads=10 --time=120 --report-interval=10 prepare
执行模式为complex，使用了10个表，每个表有10万条数据，客户端的并发线程数为10，执行时间为120秒，每10秒生成一次报告。
执行测试：
sysbench ./tests/include/oltp_legacy/oltp.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=123456 --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=100000 --threads=10 --time=120 --report-interval=10 run >> ./mysysbench.log
将测试结果导出到文件中，便于后续分析。
清理数据：
sysbench --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=123456 --mysql-db=sbtest --oltp-tables-count=10 --oltp-table-size=100000 ./tests/include/oltp_legacy/oltp.lua cleanup
执行完测试后，清理数据，否则后面的测试会受到影响。
结果分析
参数信息部分：
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)
Running the test with following options:
Number of threads: 10
Report intermediate results every 10 second(s)
Initializing random number generator from current time
中间过程信息部分：
Initializing worker threads...
Threads started!
[ 10s ] thds: 10 tps: 477.40 qps: 9560.77 (r/w/o: 6694.08/1910.89/955.80) lat (ms,95%): 29.72 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 10 tps: 451.43 qps: 9027.75 (r/w/o: 6319.48/1805.41/902.85) lat (ms,95%): 30.81 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 10 tps: 424.02 qps: 8484.10 (r/w/o: 5938.15/1697.90/848.05) lat (ms,95%): 33.12 err/s: 0.00 reconn/s: 0.00
[ 40s ] thds: 10 tps: 410.76 qps: 8212.31 (r/w/o: 5749.55/1641.24/821.52) lat (ms,95%): 34.33 err/s: 0.00 reconn/s: 0.00
[ 50s ] thds: 10 tps: 394.41 qps: 7885.10 (r/w/o: 5519.27/1577.02/788.81) lat (ms,95%): 35.59 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 10 tps: 395.00 qps: 7900.35 (r/w/o: 5530.06/1580.39/789.89) lat (ms,95%): 35.59 err/s: 0.00 reconn/s: 0.00
[ 70s ] thds: 10 tps: 387.90 qps: 7758.49 (r/w/o: 5431.66/1551.02/775.81) lat (ms,95%): 36.89 err/s: 0.00 reconn/s: 0.00
[ 80s ] thds: 10 tps: 386.48 qps: 7730.24 (r/w/o: 5410.45/1546.73/773.06) lat (ms,95%): 37.56 err/s: 0.00 reconn/s: 0.00
[ 90s ] thds: 10 tps: 396.70 qps: 7936.20 (r/w/o: 5556.07/1586.72/793.41) lat (ms,95%): 36.24 err/s: 0.00 reconn/s: 0.00
[ 100s ] thds: 10 tps: 400.21 qps: 8005.64 (r/w/o: 5604.10/1601.13/800.41) lat (ms,95%): 36.89 err/s: 0.00 reconn/s: 0.00
[ 110s ] thds: 10 tps: 398.60 qps: 7970.64 (r/w/o: 5579.33/1594.11/797.20) lat (ms,95%): 36.89 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 10 tps: 393.49 qps: 7866.67 (r/w/o: 5506.31/1573.47/786.89) lat (ms,95%): 38.94 err/s: 0.00 reconn/s: 0.00
结果统计信息部分：
SQL statistics:
queries performed:
read: 688464
write: 196704
other: 98352
total: 983520
transactions: 49176 (409.71 per sec.)
queries: 983520 (8194.14 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 120.0238s
total number of events: 49176
Latency (ms):
min: 8.24
avg: 24.40
max: 162.52
95th percentile: 35.59
sum: 1199824.71
Threads fairness:
events (avg/stddev): 4917.6000/48.05
execution time (avg/stddev): 119.9825/0.01
其中，对于我们比较重要的信息包括：
queries：查询总数及qps
transactions：事务总数及tps
Latency-95th percentile：前95%的请求的最大响应时间
使用建议
1、尽量不要在MySQL服务器运行的机器上进行测试。
2、可以逐步增加客户端的并发连接数，观察在连接数不同情况下，MySQL服务器的表现。
3、如果连续进行多次测试，注意确保之前测试的数据已经被清理干净。
4、在开始测试之前，应该首先明确：应采用针对整个系统的基准测试，还是针对MySQL的基准测试，还是二者都需要。
5、如果需要针对MySQL的基准测试，那么还需要明确精度方面的要求：是否需要使用生产环境的真实数据，还是使用工具生成也可以；前者实施起来更加繁琐。如果要使用真实数据，尽量使用全部数据，而不是部分数据。
6、基准测试要进行多次才有意义。
7、测试时需要注意主从同步的状态。
8、测试必须模拟多线程的情况，单线程情况不但无法模拟真实的效率，也无法模拟阻塞甚至死锁情况。
以上是关于高性能MySQL：运行基准测试并分析结果的主要内容，如果未能解决你的问题，请参考以下文章