尧图网站建设 
1. 认识 sysbench为什么它是性能评估的标配工具sysbench 是一款开源、跨平台的基准测试工具最初由 Alexey Kopytov 开发目前已经成为数据库管理员、运维工程师和性能测试工程师最常用的压测利器之一。它既可以用来评估服务器的 CPU、内存、磁盘 I/O 等硬件性能也可以模拟 MySQL、PostgreSQL 等数据库在高并发场景下的读写负载帮助我们量化系统的处理能力。sysbench 的核心价值在于它把「性能」从感性判断变成了可重复、可对比的数字。同样是「数据库变慢了」有人凭感觉有人看监控而使用 sysbench 的人可以直接给出 QPS每秒查询数、TPS每秒事务数以及 95 分位延迟等关键指标。这些指标不仅可以帮助我们发现瓶颈还能在更换硬件、调整参数、优化索引之后用同一套测试方法验证优化效果是否真实有效。相比 ApacheBench、jmeter、wrk 等工具sysbench 的优势在于它原生内置了多线程模型能够灵活控制并发线程数它提供统一的 Lua 脚本接口用户可以自定义复杂的测试场景它既能测硬件也能测数据库使用成本低、生态成熟非常适合在 Linux 服务器上进行基础性能摸底。2. 基准测试的基本概念与注意事项2.1 常见性能指标在开始压测之前需要先弄清楚几个频繁出现的指标它们是后续所有实验的「评分标准」。QPSQueries Per Second每秒处理的查询数量。对于 MySQL 来说一条 SQL 通常对应一次查询因此 QPS 反映的是语句执行层面的吞吐能力。TPSTransactions Per Second每秒处理的事务数量。一个事务可能包含多条 SQL例如一个下单操作可能同时包含插入订单、扣减库存、写入流水。TPS 更能反映业务层面的处理能力。延迟Latency一次请求从发出到完成所花费的时间通常以毫秒为单位。平均延迟只能反映整体水平容易掩盖长尾问题。95 分位延迟95th percentile在所有请求中95% 的请求延迟都不超过该值。例如 95 分位延迟为 20ms意味着只有 5% 的请求延迟高于 20ms。这个指标对评估用户体验非常关键。并发数同一时刻正在执行的请求数量。sysbench 使用线程数来模拟并发用户线程数越高对系统施加的压力越大。2.2 压测前必须注意的几点测试环境要尽量贴近生产不要在还挂着其他业务负载的机器上做「纯净」压测否则结果会受到干扰。建议在独立的测试环境中进行。关闭缓存干扰第一次测试结果经常偏高因为数据已经在 Buffer Pool 或操作系统 Page Cache 中。正式测试前通常先做一轮预热。多次测试取稳定结果单次测试可能存在抖动建议每个场景至少重复 3 次取中间值或平均值作为最终结论。记录硬件与环境信息CPU 型号、内存大小、磁盘类型HDD、SATA SSD、NVMe SSD、操作系统版本、MySQL 版本、关键参数配置这些信息必须和测试结果一起保存否则数据没有可比性。明确测试目标是想评估硬件极限还是想找出 MySQL 参数瓶颈还是想对比不同版本差异目标不同测试方案和关注指标也不同。3. 环境准备安装与版本确认3.1 安装 sysbench在 Debian 或 Ubuntu 系统上可以使用包管理器安装sudo apt update sudo apt install -y sysbench在 CentOS、RHEL 或 Rocky Linux 上可以先启用 EPEL 仓库再安装sudo yum install -y epel-release sudo yum install -y sysbench如果仓库中的版本较旧也可以从源码编译安装以便使用最新功能和 Lua 脚本支持。编译前需要安装依赖sudo apt install -y build-essential automake libtool pkg-config libmysqlclient-dev libssl-dev然后下载源码并编译git clone https://github.com/akopytov/sysbench.git cd sysbench ./autogen.sh ./configure --with-mysql --with-pgsql make -j8 sudo make install安装完成后验证版本sysbench --version如果输出类似sysbench 1.0.20的信息说明安装成功。1.0 及以上版本使用 LuaJIT 脚本性能更好推荐使用。3.2 准备测试用的 MySQL 环境后续的数据库测试需要一个可连接的 MySQL 实例。本文假设 MySQL 已安装并启动监听在默认端口 3306。为了便于测试需要准备一个专用账号并赋予访问测试库的权限。CREATE DATABASE IF NOT EXISTS sbtest CHARACTER SET utf8mb4; CREATE USER sbtest% IDENTIFIED BY Sbtest123; GRANT ALL PRIVILEGES ON sbtest.* TO sbtest%; FLUSH PRIVILEGES;如果使用了防火墙或安全组请确认测试客户端能够访问 MySQL 的 3306 端口。测试前也可以用 mysql 客户端手动验证连接mysql -h127.0.0.1 -P3306 -usbtest -pSbtest123 -e SELECT VERSION();4. sysbench 核心用法与通用参数sysbench 的基本命令格式为sysbench [通用选项] [测试模块] [测试指令]其中最常用的几个通用参数如下。参数作用示例--threads指定并发线程数模拟并发用户数--threads16--time测试运行时长单位秒0 表示不限制--time60--events限制执行的事件总数--events100000--report-interval每隔多少秒输出一次中间结果--report-interval10--rand-type随机数生成算法可选 uniform、gaussian、special、pareto--rand-typeuniform--percentile结果中要统计的分位数默认统计 95 分位--percentile95--db-driver数据库驱动通常为 mysql--db-drivermysql--mysql-hostMySQL 主机地址--mysql-host127.0.0.1--mysql-portMySQL 端口--mysql-port3306--mysql-user数据库用户名--mysql-usersbtest--mysql-password数据库密码--mysql-passwordpass--mysql-db目标数据库名--mysql-dbsbtestsysbench 的大部分测试模块都遵循「prepare 准备数据、run 执行测试、cleanup 清理数据」三步流程。下面先从硬件测试开始逐步过渡到 MySQL 数据库测试。5. 硬件基准测试CPU、内存与磁盘在评估 MySQL 性能之前先对服务器硬件做一轮基础测试非常重要。因为数据库的最终性能上限往往由硬件决定。如果硬件测试就显示 CPU 或磁盘存在明显瓶颈那么后续数据库调优的收益也会受限。5.1 CPU 基准测试CPU 测试通过大量计算质数来压榨处理器计算能力。命令如下sysbench cpu --threads8 --time60 run若希望每个线程执行固定数量的质数计算可以加入--cpu-max-prime参数。该值越大单次计算耗时越长sysbench cpu --threads8 --cpu-max-prime20000 --time60 run测试结束后重点关注events per second和总耗时。events per second 越高说明 CPU 计算能力越强。也可以同时开启多个终端持续压测观察 CPU 使用率、温度和频率判断是否存在降频问题。在数据库场景中CPU 单核性能往往比核心数量更能影响复杂 SQL 的处理速度。5.2 内存基准测试内存测试主要衡量 CPU 与内存之间的数据读写带宽。可以指定内存块大小和总传输数据量sysbench memory --threads8 --memory-block-size1M --memory-total-size20G run除了常规顺序读写还可以通过参数控制访问模式。内存带宽结果通常以MiB/sec形式给出。对于数据库服务器来说内存容量和带宽直接影响 InnoDB Buffer Pool 的缓存命中效率。如果内存带宽太低即使 CPU 再强数据大量读写时也会形成瓶颈。5.3 磁盘 I/O 基准测试磁盘性能是 MySQL 性能测试中最容易被忽视却极其重要的一环。InnoDB 的持久化、redo log 写入、undo 日志、页刷新都依赖磁盘。sysbench 的 fileio 模块可以测试顺序读写、随机读写等不同模式。第一步准备测试文件。下面的命令会创建 64 个文件每个文件 128MB总共约 8GBsysbench fileio --file-num64 --file-total-size8G prepare第二步执行随机读写测试sysbench fileio --file-num64 --file-total-size8G \ --file-test-moderndrw --file-block-size16K \ --threads16 --time120 --report-interval10 run常用的--file-test-mode取值包括seqwr顺序写入seqrewr顺序重写seqrd顺序读取rndrd随机读取rndwr随机写入rndrw随机读写混合测试完成后清理测试文件sysbench fileio --file-num64 cleanup在结果中read, MiB/s和written, MiB/s分别表示读取和写入吞吐。对于数据库场景随机读写的 IOPS每秒 I/O 操作数和延迟往往比顺序带宽更重要。如果测试的是 NVMe SSDIOPS 可以轻松达到数十万而传统机械硬盘的随机 IOPS 通常只有几百这种差异会直接体现在数据库写入性能上。6. MySQL 基准测试准备数据构造与测试脚本6.1 理解 sysbench 的 oltp 测试模型sysbench 自带的 oltp 脚本模拟了一个典型的电商或转账场景核心表是sbtest1到sbtestN每张表有固定数量的行。测试脚本会在这些表上执行多种 SQL点查、范围查询、排序查询、索引更新、非索引更新、插入和删除。通过这些混合操作可以较好地模拟真实业务负载。常见的 oltp 测试类型包括oltp_read_only只读场景主要由 SELECT 组成。oltp_write_only只写场景主要由 INSERT、UPDATE、DELETE 组成。oltp_read_write读写混合场景最常用适合整体性能评估。oltp_point_select纯点查场景衡量主键查询性能。oltp_update_index索引列更新场景。oltp_update_non_index非索引列更新场景。oltp_insert纯插入场景。oltp_delete纯删除场景。select_random_points、select_random_ranges随机点查和范围查询。6.2 prepare准备测试数据执行测试前需要先构造数据。下面的命令会创建 10 张表每张表 200 万行总共 2000 万行数据。数据量越大测试越接近真实场景但准备时间也越长。sysbench oltp_read_write \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads16 \ prepare准备完成后可以通过 MySQL 客户端确认数据已经生成mysql -h127.0.0.1 -P3306 -usbtest -pSbtest123 -e SHOW TABLES FROM sbtest; SELECT COUNT(*) FROM sbtest.sbtest1;数据构造阶段同样会对磁盘和 CPU 产生压力建议提前评估磁盘剩余空间。2000 万行 InnoDB 表加上索引通常需要数 GB 甚至十几 GB 空间测试前务必确认磁盘容量充足。6.3 查看测试脚本内容sysbench 使用的 Lua 脚本一般位于安装目录下可以查看脚本内容了解每个测试具体执行了哪些 SQLfind /usr/share/sysbench -name oltp_*.lua 2/dev/null如果源码编译安装也可以直接查看源码中的src/lua/oltp_common.lua。理解脚本执行内容有助于我们在结果异常时定位问题。7. MySQL 性能测试实战7.1 只读测试评估查询能力只读测试适合评估 SELECT 语句在不同并发下的性能表现。下面的命令使用 16 个线程测试 120 秒每 10 秒输出一次中间结果sysbench oltp_read_only \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads16 \ --time120 \ --report-interval10 \ run如果需要测试纯主键点查可以改用oltp_point_selectsysbench oltp_point_select \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads32 \ --time120 \ run7.2 只写测试评估写入能力只写场景对存储引擎和磁盘性能要求很高适合评估插入、更新和删除的吞吐。sysbench oltp_write_only \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads16 \ --time120 \ --report-interval10 \ run写入测试会大量产生脏页和 redo log测试期间建议同时监控磁盘 I/O 和 InnoDB 刷盘情况。如果写入 TPS 明显偏低可以从 redo log 配置、binlog 刷盘策略以及存储介质三个方向排查。7.3 读写混合测试最接近真实业务的场景读写混合测试是评估 MySQL 综合性能最常用的方式。默认情况下oltp_read_write 中读操作占比高于写操作具体比例可以通过--oltp-read-only之外的分布参数调整也可以编写自定义 Lua 脚本控制。sysbench oltp_read_write \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads64 \ --time300 \ --report-interval10 \ run建议设计一组「并发梯度测试」分别使用 8、16、32、64、128 线程各跑一轮记录 TPS、QPS 和延迟的变化。随着并发增加吞吐通常会先上升后趋于平稳甚至下降这个拐点就是系统的最优并发区间。7.4 插入与删除专项测试如果业务中存在批量导入、日志写入或数据清理场景可以单独测试插入和删除性能。sysbench oltp_insert \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads16 \ --time120 \ run删除测试执行前请注意它会删除表中的数据测试结束后数据量会减少。若后续还要做其他测试请重新执行 prepare 恢复数据。7.5 自定义 Lua 脚本当内置 oltp 脚本无法满足需求时可以编写自己的 Lua 脚本。下面是一个简单的只读查询脚本示例它随机查询指定范围的主键并执行一条按主键排序的查询。#!/usr/bin/env sysbench -- 自定义查询测试脚本 function thread_init() drv sysbench.sql.driver() con drv:connect() end function event() local id sysbench.rand.uniform(1, 100000) con:query(string.format( SELECT c FROM sbtest1 WHERE id BETWEEN %d AND %d ORDER BY id LIMIT 10, id, id 100)) end function thread_done() con:disconnect() end保存为custom_query.lua后可以这样运行sysbench custom_query.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --threads16 \ --time60 \ run自定义脚本可以精确控制 SQL 类型、比例和分布适合做更贴近业务模型的压测。建议脚本中加入必要的错误处理和打点便于后续分析。8. 深入理解测试结果sysbench 测试结束后会输出详细的统计报告。下面是一段典型的 oltp_read_write 测试输出节选SQL statistics: queries performed: read: 140000 write: 40000 other: 20000 total: 200000 transactions: 20000 (199.99 per sec.) queries: 200000 (1999.95 per sec.) ignored errors: 0 (0.00 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 100.0012s total number of events: 20000 Latency (ms): min: 4.11 avg: 80.05 max: 342.19 95th percentile: 155.80 sum: 1601024.35 Threads fairness: events (avg/stddev): 1250.0000/33.14 execution time (avg/stddev): 100.0668/0.028.1 TPS 与 QPS输出中的transactions: 199.99 per sec.表示 TPS约每秒 200 个事务queries: 1999.95 per sec.表示 QPS约每秒 2000 条查询。可以看出该场景下单事务平均包含 10 条 SQL。QPS 和 TPS 是衡量系统吞吐的核心指标数值越高代表处理能力越强但前提是要结合延迟综合判断。8.2 延迟与分位数延迟部分包含最小值、平均值、最大值和 95 分位值。在上面的例子中平均延迟 80ms但 95 分位延迟达到了 155ms说明虽然大部分请求较快但长尾延迟较为明显。如果用户对响应时间敏感95 分位、99 分位往往比平均值更有参考价值。可以通过--percentile99参数在报告中额外显示 99 分位sysbench oltp_read_write \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-usersbtest --mysql-passwordSbtest123 \ --mysql-dbsbtest --tables10 --table-size2000000 \ --threads16 --time60 --percentile99 run8.3 ignored errors 与 reconnects如果测试中出现了ignored errors或reconnects大于 0说明测试过程中发生了错误或断连。此时结果不可信需要优先排查错误原因例如测试账号权限不足、连接数超限、MySQL 崩溃或网络抖动。常见错误包括Deadlock found、Too many connections、Lost connection这些问题在压测阶段暴露出反而是好事可以提前发现生产隐患。9. 性能对比与参数调优思路9.1 并发梯度对比为了找到系统的最佳并发区间可以设计一组脚本自动用不同线程数跑测试并汇总结果。for t in 8 16 32 64 128; do echo threads: $t sysbench oltp_read_write \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-usersbtest --mysql-passwordSbtest123 \ --mysql-dbsbtest --tables10 --table-size2000000 \ --threads$t --time60 --report-interval0 run \ | grep -E transactions:|queries:|95th percentile done将每一轮结果记录到表格中观察 TPS 和 95 分位延迟随并发变化的趋势。典型规律是并发较低时 TPS 随线程数上升当接近 CPU 核数或内存、锁竞争加剧后TPS 增长放缓继续加大并发TPS 可能下降而延迟快速升高。最佳并发点通常位于吞吐接近峰值、延迟仍在可接受范围的区间。9.2 MySQL 关键参数对测试结果的影响innodb_buffer_pool_size影响数据缓存命中率。若数据集明显大于 Buffer Pool查询会频繁触发磁盘读取QPS 大幅下降。建议在内存允许的前提下尽量调大。innodb_flush_log_at_trx_commit控制 redo log 刷盘策略。取值为 0、1、2其中 1 最安全但写入开销最大2 在性能与安全之间折中0 性能最好但可能丢失数据。压测对比时可以观察该参数对写入 TPS 的影响。sync_binlog控制 binlog 刷盘频率。默认 1 表示每次提交都刷盘设为 0 可提升写入性能但增加丢失风险。max_connections若并发线程数超过该值会出现Too many connections错误需要根据测试规模调大。innodb_io_capacity影响后台刷脏页的速率。如果写入测试中脏页累积过多可能引发周期性性能抖动。对比参数调优效果时务必保持硬件和测试数据不变每次只修改一个变量才能准确归因。例如先测试sync_binlog1与sync_binlog0的写入 TPS 差异确认写入瓶颈后再做进一步调整。10. 实战案例从硬件到 MySQL 的完整评估流程下面通过一个完整案例把前面的知识串起来。假设我们新采购了一台服务器配置为 8 核 16GB 内存、NVMe SSD 数据盘需要评估它作为 MySQL 服务器的性能表现。10.1 第一步硬件摸底先执行 CPU 和内存测试确认计算与内存带宽符合预期。sysbench cpu --threads8 --time60 run sysbench memory --threads8 --memory-block-size1M --memory-total-size20G run再执行磁盘随机读写测试注意数据文件必须放在 MySQL 数据目录所在的磁盘上sysbench fileio --file-num64 --file-total-size8G prepare sysbench fileio --file-num64 --file-total-size8G \ --file-test-moderndrw --file-block-size16K \ --threads16 --time120 run sysbench fileio --file-num64 cleanup记录 CPU 的 events per second、内存带宽以及磁盘 IOPS 和吞吐建立硬件性能基线。10.2 第二步准备 MySQL 测试数据部署 MySQL 8.0设置innodb_buffer_pool_size8G然后准备测试数据。sysbench oltp_read_write \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-usersbtest --mysql-passwordSbtest123 \ --mysql-dbsbtest --tables10 --table-size2000000 \ --threads16 prepare10.3 第三步执行并发梯度测试分别以 8、16、32、64、128 线程执行读写混合测试每组 120 秒并记录 TPS、QPS 和 95 分位延迟。假设最终得到如下结果线程数TPSQPS95 分位延迟ms8850850012.51612801280016.83216501650025.46417201720048.9128158015800112.7从表中可以看出TPS 在 64 线程时接近峰值但 128 线程时延迟大幅上升且吞吐回落说明系统已经进入过载状态。因此 32 到 64 线程是该服务器较为合理的工作区间。10.4 第四步定位瓶颈并优化若发现写入 TPS 偏低可以进一步拆分只读和只写测试分别观察sysbench oltp_read_only \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-usersbtest --mysql-passwordSbtest123 \ --mysql-dbsbtest --tables10 --table-size2000000 \ --threads32 --time120 run sysbench oltp_write_only \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-usersbtest --mysql-passwordSbtest123 \ --mysql-dbsbtest --tables10 --table-size2000000 \ --threads32 --time120 run测试期间使用iostat -x 1、vmstat 1、top以及 MySQL 的SHOW ENGINE INNODB STATUS观察系统状态。若磁盘利用率接近 100%说明写入瓶颈在 I/O可考虑调整刷盘参数或更换更高性能磁盘若 CPU 使用率打满则说明计算资源成为瓶颈可以优化 SQL 或提升 CPU 规格。11. 常见问题与排错指南11.1 连接数不足现象测试过程中报错Too many connections。原因并发线程数超过了 MySQL 的max_connections限制或者连接未及时释放导致堆积。解决适当调大max_connections同时检查应用连接池和 sysbench 线程配置是否合理。11.2 测试中途出现 Deadlock现象输出中ignored errors出现死锁错误。原因读写混合场景下多个事务并发更新相同数据时可能产生死锁。少量死锁是正常现象InnoDB 会自动回滚其中一个事务。解决记录死锁次数如果占比过高需要检查 SQL 执行顺序、事务范围或索引设计减少锁竞争。11.3 数据准备非常慢现象prepare 阶段长时间未完成。原因数据量过大、磁盘写入缓慢或者未启用批量提交。解决可以调低--table-size或适当增加--threads并发准备。此外在 prepare 前临时关闭sync_binlog和innodb_flush_log_at_trx_commit能显著加速但正式测试前要恢复安全配置。11.4 结果波动大、TPS 忽高忽低现象同一场景多次测试结果差异明显。原因系统存在其他负载、缓存命中率变化、CPU 睿频或降频、临时代理干扰等。解决关闭无关服务增加预热轮次固定测试时长并进行多次重复测试取中间值。必要时检查 CPU 温度与频率策略。12. 总结sysbench 是一款上手简单、功能强大的基准测试工具但它真正的价值需要配合科学的测试方法和严谨的结果分析才能体现。本文从硬件测试出发覆盖了 CPU、内存和磁盘的基础评估再到 MySQL 的数据准备、只读、只写、读写混合和自定义 Lua 脚本测试最后结合结果解读、参数调优和完整实战案例梳理了一条可复用的性能评估路径。在实际工作中建议把「基线建立、场景测试、数据分析、瓶颈定位、优化验证」形成一个闭环。不要只迷信某一个数字而要结合 TPS、QPS、分位延迟、系统资源占用等多维信息综合判断。只有系统化地开展压测才能真正把 sysbench 变成数据库性能保障和容量规划的有力武器。 sysbench压测实战指南：从硬件到MySQL性能评估
1. 认识 sysbench为什么它是性能评估的标配工具sysbench 是一款开源、跨平台的基准测试工具最初由 Alexey Kopytov 开发目前已经成为数据库管理员、运维工程师和性能测试工程师最常用的压测利器之一。它既可以用来评估服务器的 CPU、内存、磁盘 I/O 等硬件性能也可以模拟 MySQL、PostgreSQL 等数据库在高并发场景下的读写负载帮助我们量化系统的处理能力。sysbench 的核心价值在于它把「性能」从感性判断变成了可重复、可对比的数字。同样是「数据库变慢了」有人凭感觉有人看监控而使用 sysbench 的人可以直接给出 QPS每秒查询数、TPS每秒事务数以及 95 分位延迟等关键指标。这些指标不仅可以帮助我们发现瓶颈还能在更换硬件、调整参数、优化索引之后用同一套测试方法验证优化效果是否真实有效。相比 ApacheBench、jmeter、wrk 等工具sysbench 的优势在于它原生内置了多线程模型能够灵活控制并发线程数它提供统一的 Lua 脚本接口用户可以自定义复杂的测试场景它既能测硬件也能测数据库使用成本低、生态成熟非常适合在 Linux 服务器上进行基础性能摸底。2. 基准测试的基本概念与注意事项2.1 常见性能指标在开始压测之前需要先弄清楚几个频繁出现的指标它们是后续所有实验的「评分标准」。QPSQueries Per Second每秒处理的查询数量。对于 MySQL 来说一条 SQL 通常对应一次查询因此 QPS 反映的是语句执行层面的吞吐能力。TPSTransactions Per Second每秒处理的事务数量。一个事务可能包含多条 SQL例如一个下单操作可能同时包含插入订单、扣减库存、写入流水。TPS 更能反映业务层面的处理能力。延迟Latency一次请求从发出到完成所花费的时间通常以毫秒为单位。平均延迟只能反映整体水平容易掩盖长尾问题。95 分位延迟95th percentile在所有请求中95% 的请求延迟都不超过该值。例如 95 分位延迟为 20ms意味着只有 5% 的请求延迟高于 20ms。这个指标对评估用户体验非常关键。并发数同一时刻正在执行的请求数量。sysbench 使用线程数来模拟并发用户线程数越高对系统施加的压力越大。2.2 压测前必须注意的几点测试环境要尽量贴近生产不要在还挂着其他业务负载的机器上做「纯净」压测否则结果会受到干扰。建议在独立的测试环境中进行。关闭缓存干扰第一次测试结果经常偏高因为数据已经在 Buffer Pool 或操作系统 Page Cache 中。正式测试前通常先做一轮预热。多次测试取稳定结果单次测试可能存在抖动建议每个场景至少重复 3 次取中间值或平均值作为最终结论。记录硬件与环境信息CPU 型号、内存大小、磁盘类型HDD、SATA SSD、NVMe SSD、操作系统版本、MySQL 版本、关键参数配置这些信息必须和测试结果一起保存否则数据没有可比性。明确测试目标是想评估硬件极限还是想找出 MySQL 参数瓶颈还是想对比不同版本差异目标不同测试方案和关注指标也不同。3. 环境准备安装与版本确认3.1 安装 sysbench在 Debian 或 Ubuntu 系统上可以使用包管理器安装sudo apt update sudo apt install -y sysbench在 CentOS、RHEL 或 Rocky Linux 上可以先启用 EPEL 仓库再安装sudo yum install -y epel-release sudo yum install -y sysbench如果仓库中的版本较旧也可以从源码编译安装以便使用最新功能和 Lua 脚本支持。编译前需要安装依赖sudo apt install -y build-essential automake libtool pkg-config libmysqlclient-dev libssl-dev然后下载源码并编译git clone https://github.com/akopytov/sysbench.git cd sysbench ./autogen.sh ./configure --with-mysql --with-pgsql make -j8 sudo make install安装完成后验证版本sysbench --version如果输出类似sysbench 1.0.20的信息说明安装成功。1.0 及以上版本使用 LuaJIT 脚本性能更好推荐使用。3.2 准备测试用的 MySQL 环境后续的数据库测试需要一个可连接的 MySQL 实例。本文假设 MySQL 已安装并启动监听在默认端口 3306。为了便于测试需要准备一个专用账号并赋予访问测试库的权限。CREATE DATABASE IF NOT EXISTS sbtest CHARACTER SET utf8mb4; CREATE USER sbtest% IDENTIFIED BY Sbtest123; GRANT ALL PRIVILEGES ON sbtest.* TO sbtest%; FLUSH PRIVILEGES;如果使用了防火墙或安全组请确认测试客户端能够访问 MySQL 的 3306 端口。测试前也可以用 mysql 客户端手动验证连接mysql -h127.0.0.1 -P3306 -usbtest -pSbtest123 -e SELECT VERSION();4. sysbench 核心用法与通用参数sysbench 的基本命令格式为sysbench [通用选项] [测试模块] [测试指令]其中最常用的几个通用参数如下。参数作用示例--threads指定并发线程数模拟并发用户数--threads16--time测试运行时长单位秒0 表示不限制--time60--events限制执行的事件总数--events100000--report-interval每隔多少秒输出一次中间结果--report-interval10--rand-type随机数生成算法可选 uniform、gaussian、special、pareto--rand-typeuniform--percentile结果中要统计的分位数默认统计 95 分位--percentile95--db-driver数据库驱动通常为 mysql--db-drivermysql--mysql-hostMySQL 主机地址--mysql-host127.0.0.1--mysql-portMySQL 端口--mysql-port3306--mysql-user数据库用户名--mysql-usersbtest--mysql-password数据库密码--mysql-passwordpass--mysql-db目标数据库名--mysql-dbsbtestsysbench 的大部分测试模块都遵循「prepare 准备数据、run 执行测试、cleanup 清理数据」三步流程。下面先从硬件测试开始逐步过渡到 MySQL 数据库测试。5. 硬件基准测试CPU、内存与磁盘在评估 MySQL 性能之前先对服务器硬件做一轮基础测试非常重要。因为数据库的最终性能上限往往由硬件决定。如果硬件测试就显示 CPU 或磁盘存在明显瓶颈那么后续数据库调优的收益也会受限。5.1 CPU 基准测试CPU 测试通过大量计算质数来压榨处理器计算能力。命令如下sysbench cpu --threads8 --time60 run若希望每个线程执行固定数量的质数计算可以加入--cpu-max-prime参数。该值越大单次计算耗时越长sysbench cpu --threads8 --cpu-max-prime20000 --time60 run测试结束后重点关注events per second和总耗时。events per second 越高说明 CPU 计算能力越强。也可以同时开启多个终端持续压测观察 CPU 使用率、温度和频率判断是否存在降频问题。在数据库场景中CPU 单核性能往往比核心数量更能影响复杂 SQL 的处理速度。5.2 内存基准测试内存测试主要衡量 CPU 与内存之间的数据读写带宽。可以指定内存块大小和总传输数据量sysbench memory --threads8 --memory-block-size1M --memory-total-size20G run除了常规顺序读写还可以通过参数控制访问模式。内存带宽结果通常以MiB/sec形式给出。对于数据库服务器来说内存容量和带宽直接影响 InnoDB Buffer Pool 的缓存命中效率。如果内存带宽太低即使 CPU 再强数据大量读写时也会形成瓶颈。5.3 磁盘 I/O 基准测试磁盘性能是 MySQL 性能测试中最容易被忽视却极其重要的一环。InnoDB 的持久化、redo log 写入、undo 日志、页刷新都依赖磁盘。sysbench 的 fileio 模块可以测试顺序读写、随机读写等不同模式。第一步准备测试文件。下面的命令会创建 64 个文件每个文件 128MB总共约 8GBsysbench fileio --file-num64 --file-total-size8G prepare第二步执行随机读写测试sysbench fileio --file-num64 --file-total-size8G \ --file-test-moderndrw --file-block-size16K \ --threads16 --time120 --report-interval10 run常用的--file-test-mode取值包括seqwr顺序写入seqrewr顺序重写seqrd顺序读取rndrd随机读取rndwr随机写入rndrw随机读写混合测试完成后清理测试文件sysbench fileio --file-num64 cleanup在结果中read, MiB/s和written, MiB/s分别表示读取和写入吞吐。对于数据库场景随机读写的 IOPS每秒 I/O 操作数和延迟往往比顺序带宽更重要。如果测试的是 NVMe SSDIOPS 可以轻松达到数十万而传统机械硬盘的随机 IOPS 通常只有几百这种差异会直接体现在数据库写入性能上。6. MySQL 基准测试准备数据构造与测试脚本6.1 理解 sysbench 的 oltp 测试模型sysbench 自带的 oltp 脚本模拟了一个典型的电商或转账场景核心表是sbtest1到sbtestN每张表有固定数量的行。测试脚本会在这些表上执行多种 SQL点查、范围查询、排序查询、索引更新、非索引更新、插入和删除。通过这些混合操作可以较好地模拟真实业务负载。常见的 oltp 测试类型包括oltp_read_only只读场景主要由 SELECT 组成。oltp_write_only只写场景主要由 INSERT、UPDATE、DELETE 组成。oltp_read_write读写混合场景最常用适合整体性能评估。oltp_point_select纯点查场景衡量主键查询性能。oltp_update_index索引列更新场景。oltp_update_non_index非索引列更新场景。oltp_insert纯插入场景。oltp_delete纯删除场景。select_random_points、select_random_ranges随机点查和范围查询。6.2 prepare准备测试数据执行测试前需要先构造数据。下面的命令会创建 10 张表每张表 200 万行总共 2000 万行数据。数据量越大测试越接近真实场景但准备时间也越长。sysbench oltp_read_write \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads16 \ prepare准备完成后可以通过 MySQL 客户端确认数据已经生成mysql -h127.0.0.1 -P3306 -usbtest -pSbtest123 -e SHOW TABLES FROM sbtest; SELECT COUNT(*) FROM sbtest.sbtest1;数据构造阶段同样会对磁盘和 CPU 产生压力建议提前评估磁盘剩余空间。2000 万行 InnoDB 表加上索引通常需要数 GB 甚至十几 GB 空间测试前务必确认磁盘容量充足。6.3 查看测试脚本内容sysbench 使用的 Lua 脚本一般位于安装目录下可以查看脚本内容了解每个测试具体执行了哪些 SQLfind /usr/share/sysbench -name oltp_*.lua 2/dev/null如果源码编译安装也可以直接查看源码中的src/lua/oltp_common.lua。理解脚本执行内容有助于我们在结果异常时定位问题。7. MySQL 性能测试实战7.1 只读测试评估查询能力只读测试适合评估 SELECT 语句在不同并发下的性能表现。下面的命令使用 16 个线程测试 120 秒每 10 秒输出一次中间结果sysbench oltp_read_only \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads16 \ --time120 \ --report-interval10 \ run如果需要测试纯主键点查可以改用oltp_point_selectsysbench oltp_point_select \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads32 \ --time120 \ run7.2 只写测试评估写入能力只写场景对存储引擎和磁盘性能要求很高适合评估插入、更新和删除的吞吐。sysbench oltp_write_only \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads16 \ --time120 \ --report-interval10 \ run写入测试会大量产生脏页和 redo log测试期间建议同时监控磁盘 I/O 和 InnoDB 刷盘情况。如果写入 TPS 明显偏低可以从 redo log 配置、binlog 刷盘策略以及存储介质三个方向排查。7.3 读写混合测试最接近真实业务的场景读写混合测试是评估 MySQL 综合性能最常用的方式。默认情况下oltp_read_write 中读操作占比高于写操作具体比例可以通过--oltp-read-only之外的分布参数调整也可以编写自定义 Lua 脚本控制。sysbench oltp_read_write \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads64 \ --time300 \ --report-interval10 \ run建议设计一组「并发梯度测试」分别使用 8、16、32、64、128 线程各跑一轮记录 TPS、QPS 和延迟的变化。随着并发增加吞吐通常会先上升后趋于平稳甚至下降这个拐点就是系统的最优并发区间。7.4 插入与删除专项测试如果业务中存在批量导入、日志写入或数据清理场景可以单独测试插入和删除性能。sysbench oltp_insert \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --tables10 \ --table-size2000000 \ --threads16 \ --time120 \ run删除测试执行前请注意它会删除表中的数据测试结束后数据量会减少。若后续还要做其他测试请重新执行 prepare 恢复数据。7.5 自定义 Lua 脚本当内置 oltp 脚本无法满足需求时可以编写自己的 Lua 脚本。下面是一个简单的只读查询脚本示例它随机查询指定范围的主键并执行一条按主键排序的查询。#!/usr/bin/env sysbench -- 自定义查询测试脚本 function thread_init() drv sysbench.sql.driver() con drv:connect() end function event() local id sysbench.rand.uniform(1, 100000) con:query(string.format( SELECT c FROM sbtest1 WHERE id BETWEEN %d AND %d ORDER BY id LIMIT 10, id, id 100)) end function thread_done() con:disconnect() end保存为custom_query.lua后可以这样运行sysbench custom_query.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest123 \ --mysql-dbsbtest \ --threads16 \ --time60 \ run自定义脚本可以精确控制 SQL 类型、比例和分布适合做更贴近业务模型的压测。建议脚本中加入必要的错误处理和打点便于后续分析。8. 深入理解测试结果sysbench 测试结束后会输出详细的统计报告。下面是一段典型的 oltp_read_write 测试输出节选SQL statistics: queries performed: read: 140000 write: 40000 other: 20000 total: 200000 transactions: 20000 (199.99 per sec.) queries: 200000 (1999.95 per sec.) ignored errors: 0 (0.00 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 100.0012s total number of events: 20000 Latency (ms): min: 4.11 avg: 80.05 max: 342.19 95th percentile: 155.80 sum: 1601024.35 Threads fairness: events (avg/stddev): 1250.0000/33.14 execution time (avg/stddev): 100.0668/0.028.1 TPS 与 QPS输出中的transactions: 199.99 per sec.表示 TPS约每秒 200 个事务queries: 1999.95 per sec.表示 QPS约每秒 2000 条查询。可以看出该场景下单事务平均包含 10 条 SQL。QPS 和 TPS 是衡量系统吞吐的核心指标数值越高代表处理能力越强但前提是要结合延迟综合判断。8.2 延迟与分位数延迟部分包含最小值、平均值、最大值和 95 分位值。在上面的例子中平均延迟 80ms但 95 分位延迟达到了 155ms说明虽然大部分请求较快但长尾延迟较为明显。如果用户对响应时间敏感95 分位、99 分位往往比平均值更有参考价值。可以通过--percentile99参数在报告中额外显示 99 分位sysbench oltp_read_write \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-usersbtest --mysql-passwordSbtest123 \ --mysql-dbsbtest --tables10 --table-size2000000 \ --threads16 --time60 --percentile99 run8.3 ignored errors 与 reconnects如果测试中出现了ignored errors或reconnects大于 0说明测试过程中发生了错误或断连。此时结果不可信需要优先排查错误原因例如测试账号权限不足、连接数超限、MySQL 崩溃或网络抖动。常见错误包括Deadlock found、Too many connections、Lost connection这些问题在压测阶段暴露出反而是好事可以提前发现生产隐患。9. 性能对比与参数调优思路9.1 并发梯度对比为了找到系统的最佳并发区间可以设计一组脚本自动用不同线程数跑测试并汇总结果。for t in 8 16 32 64 128; do echo threads: $t sysbench oltp_read_write \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-usersbtest --mysql-passwordSbtest123 \ --mysql-dbsbtest --tables10 --table-size2000000 \ --threads$t --time60 --report-interval0 run \ | grep -E transactions:|queries:|95th percentile done将每一轮结果记录到表格中观察 TPS 和 95 分位延迟随并发变化的趋势。典型规律是并发较低时 TPS 随线程数上升当接近 CPU 核数或内存、锁竞争加剧后TPS 增长放缓继续加大并发TPS 可能下降而延迟快速升高。最佳并发点通常位于吞吐接近峰值、延迟仍在可接受范围的区间。9.2 MySQL 关键参数对测试结果的影响innodb_buffer_pool_size影响数据缓存命中率。若数据集明显大于 Buffer Pool查询会频繁触发磁盘读取QPS 大幅下降。建议在内存允许的前提下尽量调大。innodb_flush_log_at_trx_commit控制 redo log 刷盘策略。取值为 0、1、2其中 1 最安全但写入开销最大2 在性能与安全之间折中0 性能最好但可能丢失数据。压测对比时可以观察该参数对写入 TPS 的影响。sync_binlog控制 binlog 刷盘频率。默认 1 表示每次提交都刷盘设为 0 可提升写入性能但增加丢失风险。max_connections若并发线程数超过该值会出现Too many connections错误需要根据测试规模调大。innodb_io_capacity影响后台刷脏页的速率。如果写入测试中脏页累积过多可能引发周期性性能抖动。对比参数调优效果时务必保持硬件和测试数据不变每次只修改一个变量才能准确归因。例如先测试sync_binlog1与sync_binlog0的写入 TPS 差异确认写入瓶颈后再做进一步调整。10. 实战案例从硬件到 MySQL 的完整评估流程下面通过一个完整案例把前面的知识串起来。假设我们新采购了一台服务器配置为 8 核 16GB 内存、NVMe SSD 数据盘需要评估它作为 MySQL 服务器的性能表现。10.1 第一步硬件摸底先执行 CPU 和内存测试确认计算与内存带宽符合预期。sysbench cpu --threads8 --time60 run sysbench memory --threads8 --memory-block-size1M --memory-total-size20G run再执行磁盘随机读写测试注意数据文件必须放在 MySQL 数据目录所在的磁盘上sysbench fileio --file-num64 --file-total-size8G prepare sysbench fileio --file-num64 --file-total-size8G \ --file-test-moderndrw --file-block-size16K \ --threads16 --time120 run sysbench fileio --file-num64 cleanup记录 CPU 的 events per second、内存带宽以及磁盘 IOPS 和吞吐建立硬件性能基线。10.2 第二步准备 MySQL 测试数据部署 MySQL 8.0设置innodb_buffer_pool_size8G然后准备测试数据。sysbench oltp_read_write \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-usersbtest --mysql-passwordSbtest123 \ --mysql-dbsbtest --tables10 --table-size2000000 \ --threads16 prepare10.3 第三步执行并发梯度测试分别以 8、16、32、64、128 线程执行读写混合测试每组 120 秒并记录 TPS、QPS 和 95 分位延迟。假设最终得到如下结果线程数TPSQPS95 分位延迟ms8850850012.51612801280016.83216501650025.46417201720048.9128158015800112.7从表中可以看出TPS 在 64 线程时接近峰值但 128 线程时延迟大幅上升且吞吐回落说明系统已经进入过载状态。因此 32 到 64 线程是该服务器较为合理的工作区间。10.4 第四步定位瓶颈并优化若发现写入 TPS 偏低可以进一步拆分只读和只写测试分别观察sysbench oltp_read_only \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-usersbtest --mysql-passwordSbtest123 \ --mysql-dbsbtest --tables10 --table-size2000000 \ --threads32 --time120 run sysbench oltp_write_only \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-usersbtest --mysql-passwordSbtest123 \ --mysql-dbsbtest --tables10 --table-size2000000 \ --threads32 --time120 run测试期间使用iostat -x 1、vmstat 1、top以及 MySQL 的SHOW ENGINE INNODB STATUS观察系统状态。若磁盘利用率接近 100%说明写入瓶颈在 I/O可考虑调整刷盘参数或更换更高性能磁盘若 CPU 使用率打满则说明计算资源成为瓶颈可以优化 SQL 或提升 CPU 规格。11. 常见问题与排错指南11.1 连接数不足现象测试过程中报错Too many connections。原因并发线程数超过了 MySQL 的max_connections限制或者连接未及时释放导致堆积。解决适当调大max_connections同时检查应用连接池和 sysbench 线程配置是否合理。11.2 测试中途出现 Deadlock现象输出中ignored errors出现死锁错误。原因读写混合场景下多个事务并发更新相同数据时可能产生死锁。少量死锁是正常现象InnoDB 会自动回滚其中一个事务。解决记录死锁次数如果占比过高需要检查 SQL 执行顺序、事务范围或索引设计减少锁竞争。11.3 数据准备非常慢现象prepare 阶段长时间未完成。原因数据量过大、磁盘写入缓慢或者未启用批量提交。解决可以调低--table-size或适当增加--threads并发准备。此外在 prepare 前临时关闭sync_binlog和innodb_flush_log_at_trx_commit能显著加速但正式测试前要恢复安全配置。11.4 结果波动大、TPS 忽高忽低现象同一场景多次测试结果差异明显。原因系统存在其他负载、缓存命中率变化、CPU 睿频或降频、临时代理干扰等。解决关闭无关服务增加预热轮次固定测试时长并进行多次重复测试取中间值。必要时检查 CPU 温度与频率策略。12. 总结sysbench 是一款上手简单、功能强大的基准测试工具但它真正的价值需要配合科学的测试方法和严谨的结果分析才能体现。本文从硬件测试出发覆盖了 CPU、内存和磁盘的基础评估再到 MySQL 的数据准备、只读、只写、读写混合和自定义 Lua 脚本测试最后结合结果解读、参数调优和完整实战案例梳理了一条可复用的性能评估路径。在实际工作中建议把「基线建立、场景测试、数据分析、瓶颈定位、优化验证」形成一个闭环。不要只迷信某一个数字而要结合 TPS、QPS、分位延迟、系统资源占用等多维信息综合判断。只有系统化地开展压测才能真正把 sysbench 变成数据库性能保障和容量规划的有力武器。