sysbench 这个压力测试工具我前后用了快十年。从最早拿它压本机 CPU、内存带宽到后来专门用来做 MySQL 的读写基准验证它在我的工具箱里一直是参数直白、行为可预期的存在。现在的压测工具多了不少有图形化的、有出报告特别漂亮的但我做上架前验收、调优前后对比、容量评估这类事情时还是会第一时间掏出 sysbench。这篇文章不是一个命令手册的翻译而是我多年实测下来的经验总结。我会讲清楚它到底能压什么、每条参数背后的含义、输出数据怎么读以及最重要的——一个完整的 MySQL 读写压测应该怎么做。内容对刚接触服务器性能测试的新手友好也能让已经用过一段时间、但只停留在跑个默认 cpu 测试阶段的人真正进阶。1. 为什么压测我还是会掏出 sysbench 而不是更花哨的工具先说结论sysbench 的价值在于它的覆盖面广和行为可预期。它不是一个只盯着数据库的压测工具而是一个通用系统基准测试工具。CPU、内存、文件 I/O、线程调度、互斥锁再到关系型数据库的 OLTP 基准全都能测。我经常在一个新服务器上用它五分钟内先跑完 CPU 和内存基准确认硬件没有明显问题然后再进入数据库层面的压测。一个 Jenkins 任务调用的就是同一套命令跑进 CI 后它的稳定性和输出可解析性比那些仪表盘华丽的工具强得多。很多人会问压数据库我用 mysqlslap 或者 pgbench 不就行了确实行但有一个区别。sysbench 的 OLTP 脚本本质是用 Lua 写的、自带事务编排逻辑的一套模拟协议它模拟的是多个客户端会话持续执行增删改查并提交事务的业务负载而不是像 mysqlslap 那样单纯并发跑几条 SQL。更关键的是sysbench 支持Lua 脚本自定义。你可以按自己的业务表结构去造数据、去写查询语句而不是被困在默认的几条 SQL 里。这一条就让它比很多专用工具灵活。我归纳了一下平时最常用的场景场景使用模块我一般看的关键指标新到货服务器的 CPU 性能验证cpuevents per second内存带宽与延迟粗检memory吞吐量 MB/s延迟分位磁盘/云盘的裸性能测试fileioIOPS 与延迟分位云服务器连续多轮跑分对比cpumemory多轮结果稳定性数据库读写与事务能力评估oltp_read_write等TPS、QPS、延迟分位SQL 脚本/业务流改造验证自定义 Lua按具体业务定义成功率从这张表也能看出来sysbench 在系统级基准和数据库级压力两个层面都站得住。这是很多工具做不到的因为它们要么只能压 CPU要么只能压 SQL。另外我比较看重的一点是它的跨版本稳定性。我最早用的 0.4到后来的 1.0再到现在的 1.1核心参数的命名和输出格式基本延续了下来。这意味着我五年前写的压测脚本现在只需要改极少的地方就能继续用。做性能测试最怕的就是工具版本一换、参数全变导致历史数据没法对比。sysbench 在这方面给了我很大的安全感。2. 装好之后第一件事跑通 sysbench 自带的 cpu 和 memory 基准sysbench 的安装没有太多可说的但我还是想提醒一个事不要把发行版自带的旧版 sysbench 当成最终版本直接用。有些老系统的源里还是 0.4 甚至更早的版本它的参数体系和新版差得很大。你搜网上教程的时候如果发现命令写的是--testcpu这种老格式那大概率是旧版。我建议直接用新版自己编译也不麻烦。2.1 安装中的两个实际注意点在新一点的 Debian/Ubuntu 上用apt install sysbenchCentOS/Rocky 上用dnf install sysbench通常都能拿到 1.0 以后的版本。但这些发行版自带包可能不是最新修复版如果你对某些 OLTP 脚本的细节行为有要求我更推荐源码安装curl -L -o sysbench.tar.gz https://github.com/akopytov/sysbench/archive/refs/tags/1.1.0.tar.gz tar xf sysbench.tar.gz cd sysbench-1.1.0 ./autogen.sh ./configure --with-mysql make -j$(nproc) sudo make install这里有个细节configure时我习惯加上--with-mysql这样会同时编译出数据库压测所需的oltp_*.lua脚本和驱动。如果你只做 CPU、磁盘类的测试不加 MySQL 支持也行但数据库压测那章的内容就做不了了。编译前机器上需要有libmysqlclient-dev这类开发包缺了它会直接提示找不到 mysql.h。装完之后务必确认一下版本我一般这么看sysbench --version如果输出sysbench 1.1.0脚本目录在/usr/local/share/sysbench/下能找到oltp_read_write.lua等文件说明装得没问题。这个脚本目录路径很关键后面跑数据库压测时你总会跟它打交道。2.2 首次压测看清 CPU 输出中的这几个数字装好后我建议新手跑的第一个测试不是数据库而是 CPU 基准。因为它不需要任何前置准备一条命令见真章sysbench cpu --threads4 --time30 --events0 run跑出来的结果里最关键的是events per second它代表每秒事件数。sysbench 的cpu模块做的事很简单每个线程循环计算指定范围内的质数每算完一轮记一个 event。所以这个数字越大说明 CPU 在这个特定计算模型下跑得越快。这块我给一个非常实用的经验连续跑三到五次看事件数是否稳定。如果数值上下波动超过 3% 到 5%先别急着下结论要确认机器的频率策略。现在的服务器 CPU 有睿频机制压测前系统负载低时前几秒频率可能没拉满容易让人误判性能。我一般会在正式测试前先跑一个--time5的预热让频率和温度都稳定下来然后再用--time60做正式记录。顺带一提--events0表示不限制总事件数只按时间停止。--time30则是最大运行 30 秒。很多教程会漏掉--events0导致压测在某个固定事件数下提前结束数据不够充分。你要根据场景自己选但我在做系统级测试时更常用按时间结束的模式。2.3 内存测试的误区它测的不是容量而是搬运速度内存测试的常见误解是觉得它能测试内存容量是否正确、ECC 是否生效。实际上sysbench 的memory模块做的是读写内存块操作的吞吐和延迟本质是测试内存带宽和访问延迟不是测试容量。我常用的内存测试命令sysbench memory --threads2 --memory-block-size1M --memory-total-size10G --memory-operread run sysbench memory --threads2 --memory-block-size1M --memory-total-size10G --memory-operwrite run这里需要解释两个参数。--memory-block-size是每次操作搬运的数据块大小块越大越能体现连续内存的带宽--memory-total-size是所有线程总共搬运的数据量10G是我在内存大于 16G 的机器上常用的量级。数据量太小容易受缓存影响数据量太大又会让测试时间变得过长。读操作和写操作要分开测因为大部分场景下读吞吐会比写快。输出里的Total operations、MiB transferred、MB/sec这三个值比较关键其中MB/sec就是内存吞吐。做多线程测试时注意--threads不要无脑开到几十甚至上百因为内存控制器本来就能并行处理一定数量的请求线程数太多反而会让锁竞争干扰测试目标。我在单路服务器上的经验值是 CPU 核数的一半到两倍之间别超过太多。3. 数据库压测的关键看懂输出、配好参数、改对自己的脚本如果说 CPU 和内存测试只是热身那 sysbench 真正让人又爱又恨的地方是它的数据库压测。爱是因为它足够强大恨是因为参数太多输出数据结构复杂稍不留神就跑出不具参考意义的数据。跑数据库压测之前先理解它的整体三段式流程prepare阶段建表、插入指定数量的测试行 run阶段真正并发执行压测脚本 cleanup阶段清理掉测试表这三阶段用的基本是同一个脚本入口靠prepare、run、cleanup三个子命令区分。我第一次用的时候没搞清这个逻辑直接跑run结果报错说表不存在后来才知道要先prepare。现在倒觉得这个三段式设计很干净它把造数据跑压力收尾彻底分开了特别适合自动化集成。3.1 核心参数对照表一眼看清每个参数的用途我把平时最常用的参数整理成一张表方便你查参数含义我的常用值备注--threadsN并发线程数16/32/64不是越大越好见下文--eventsN总事件数上限00 表示不限制按时间跑--timeN最大运行秒数60/120现场压测我常用 300--report-intervalN每 N 秒打印一次中间统计10用于观察波动--rateN限制每秒事件数不设置主要用于限速模拟--tablesN测试表数量16多表更贴近真实业务--table-sizeN每张表的行数100000行数过少缓存干扰大--mysql-host/--mysql-port数据库地址端口-本机测试也要写走 TCP--mysql-user/--mysql-password账号密码-建议专用账号--mysql-db目标库sbtest需要提前创建--db-drivermysql驱动类型mysql压 pg 则写 pgsql--db-ps-modedisableSQL 预处理开关disable见下文解释这里我得专门展开说一个参数--db-ps-modedisable。默认情况下 sysbench 会使用 MySQL 预处理语句prepared statement这能让 SQL 执行计划在多次执行中被复用缩短单条 SQL 的耗时。但如果你压测的目标是排查慢查询、评估真实业务的 SQL 解析与执行全链路成本预处理会掩盖一部分开销。我习惯在 OLTP 基准中用disable把 SQL 准备过程也纳入压力范围这样跑出来的结果更贴近一个不懂复用执行计划的普通业务连接的真实表现。当然如果你想模拟大量使用 ORM 预处理语句的系统那就保持默认的自动模式。这个选择会直接影响你的 TPS 数据对比测试时前后要一致。3.2 输出数据读法TPS、QPS、百分位延迟各有各的读法第一次跑 sysbench 数据库压测的时候很多人会懵屏幕上既有一堆read/write的吞吐数据又有一个延迟汇总还时不时刷新中间报告。完整结果里最核心的是两部分SQL statistics: queries performed: read: 425600 write: 121600 other: 51200 total: 598400 transactions: 6400 (1280.00 per sec.) queries: 85120 (17024.00 per sec.) ignored errors: 0 (0.00 per sec.) reconnects: 0 (0.00 per sec.) Latency (ms): min: 23.45 avg: 127.38 max: 984.22 95th percentile: 412.76 sum: 815232.11第一行的transactions后面的括号数字就是TPS即每秒事务数。第二行的queries括号数字是QPS。这两个数字是整个压测报告最核心的指标。事务在这里指一组完整的读写 SQL 组合一次事务可能包含多条 SQL所以 QPS 一般远高于 TPS。延迟统计里avg是所有事务的平均耗时95th percentile表示有 95% 的事务延迟低于这个数。我特别建议你先看95th percentile而不是avg因为数据库偶尔会出现长尾请求把平均值拉高但 95 分位能更真实反映绝大多数请求体感多快。比如上面的结果里 avg 是 127ms看起来还行但 95 分位已经到 412ms说明尾部请求有明显卡顿。这种数据如果只看 avg你很可能会误判系统性能。中间过程报告来自--report-interval10这类参数。它能在跑的过程中每 10 秒刷新一次 tps、qps、延迟数据。做现场故障排查时我特别依赖这个输出它能让我看到压力慢慢上来时性能是不是线性变化还是到了某个时间点突然断崖式下跌——后者往往意味着发生了锁等待、连接耗尽或内存交换。3.3 为什么我不建议无脑把 --threads 拉到上百有个非常经典的坑把--threads从 16 翻到 64TPS 可能涨了但延迟跟着也涨了再翻到 128TPS 反而可能下降。原因很简单并发线程数超过数据库处理能力后请求开始排队而不是并行处理。排队时间越长延迟越高TPS 不再增长甚至因为资源竞争而下滑。我做容量评估时一般这样测试从 8 个线程开始按照 16、32、64、128 的梯度依次跑每轮跑完记录 TPS 和 95 分位延迟然后画一条并发数—TPS的曲线。曲线上最后那个TPS 增长幅度小于 5% 的线程数基本就是这个系统的建议并发上限。这个值对后续配置连接池大小非常有参考价值——我见过不少团队的连接池配了 200 个连接实际压测显示 64 连接时性价比最高200 连接只是让线程全部堆积在数据库侧。4. 一次完整的 MySQL 读写混合压测应该怎么做前面讲了不少原理现在来一次完整的实战。这一节我按自己常用的标准流程来走你可以直接当模板用。4.1 准备压测库、账号与表结构先在 MySQL 里创建数据库和账号这一步很多人会漏掉。sysbench 的prepare不会帮你创建数据库只会建表。我用的一套标准准备 SQL 是CREATE DATABASE IF NOT EXISTS sbtest CHARACTER SET utf8mb4; CREATE USER IF NOT EXISTS sbtest% IDENTIFIED BY sbtest123; GRANT ALL PRIVILEGES ON sbtest.* TO sbtest%; FLUSH PRIVILEGES;为什么要单独建一个专用账号因为压测时会产生大量连接如果复用业务的正式账号一来可能触发权限审计告警二来错误日志里会被压测报错刷屏影响你对真实问题的判断。专用的 sbtest 账号用完随时可以清理权限也限制在这个库内风险可控。然后跑prepare生成 16 张表每张 10 万行sysbench /usr/local/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordsbtest123 \ --mysql-dbsbtest \ --tables16 \ --table-size100000 \ --threads16 \ prepare这条路走到一半最容易出的问题有几种提示Table sbtest.sbtest1 doesnt exist说明你还没跑过 prepare提示权限不足说明账号授权时没给到对应库卡在插入很久没反应多半是表数量和数据行数设得太大或者磁盘刷脏页很慢。我自己的经验是压测前先跑通一次小数据量的全过程。比如先用--tables4 --table-size10000跑一遍 prepare→run→cleanup确认脚本和参数没问题再上正式容量。这能省下大量排错时间因为你不会知道是脚本问题还是资源瓶颈。4.2 正式压测长时间比短时间更能说明问题我见过很多人在压测时用--time10这是非常不推荐的做法。10 秒太短数据库的缓冲池都还没热起来CPU 频率也未必稳定跑出来的数据只能算误差。我自己在现场做基准测试时最少用 60 秒正式记录用 120 秒排查性能波动时会跑到 300 秒。正式读写混合压测命令sysbench /usr/local/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordsbtest123 \ --mysql-dbsbtest \ --tables16 \ --table-size100000 \ --threads32 \ --time120 \ --report-interval10 \ --db-ps-modedisable \ run跑的时候我习惯在旁边开一个终端用top或者htop观察 CPU 和内存再开另一个窗口看 MySQL 的show processlist。为什么要看这些因为 sysbench 跑出来的数字再漂亮也要结合服务器资源使用情况才能下结论。比如 TPS 只有 500CPU 利用率却已经 100%说明瓶颈可能在 CPU 计算而不是数据库层面如果 TPS 使用 32 线程和 16 线程差不多CPU 也没吃满那就要怀疑是不是锁等待或者 IO 卡顿。我还会顺带看 MySQL 的线程状态。如果 processlist 里大量线程卡在statistics或Sending data那通常是单条 SQL 性能差导致的如果大量线程卡在Updating或update则更可能是写锁竞争。这些东西 sysbench 本身并不会直接告诉你需要你人肉关联来看这也正是实战二字比跑命令更值钱的地方。4.3 压完怎么清理数据压测完成后不要忘了清理环境。虽说留着测试表问题也不大但如果你是在生产库旁边开的临时环境或者压测完后要继续装监控系统测试表会污染后续指标。清理命令很简单sysbench /usr/local/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordsbtest123 \ --mysql-dbsbtest \ --tables16 \ --table-size100000 \ cleanup清理之后确认一下SHOW TABLES;是否为空。有些版本在清理过程中如果遇到连接中断可能会残留部分表需要手动DROP TABLE。这个细节很小但对自动化脚本的幂等性影响很大——一个重新执行清理会报错的脚本集成到 CI 里会非常难受。5. 自定义 Lua 压测脚本让 sysbench 真正贴合业务默认的oltp_read_write是一个通用的 TPCC 风格基准简单好用但它和你的真实业务相比SQL 模型差异可能非常大。比如你的业务绝大部分是单条主键查询很少写再比如你有一个报表系统查询时间很长、并发也不高。用默认脚本压出来的数据只能代表sysbench 模拟的通用负载不能代表你的业务跑在这个机器上的表现。所以真正会用 sysbench 的人都会改脚本。5.1 脚本结构骨架三件事一个最小可用的 Lua 脚本长这样。我习惯把它放在/root/scripts/或者项目目录下文件名自取比如my_select.luafunction thread_init(thread_id) -- 每个线程开始时执行一次在这里初始化专用连接或变量 end function thread_done(thread_id) -- 线程结束时执行一般用来关闭连接 end function event() -- 这是核心函数每触发一个 event 就执行一次 -- 一般在这里构造 SQL 并执行 local table_name sbtest1 local k math.random(1, 100000) local rs db_conn:query(SELECT c FROM .. table_name .. WHERE id .. k) endsysbench 执行 Lua 脚本的机制是每个 worker 线程在初始化时调用thread_init然后不断循环调用event直到到达期望的--events总数或--time时间上限。event每执行一次就算一个 event。所以events per second实际上就是每秒执行了多少次event。理解这个结构之后你就会明白自定义脚本的本质是你只要控制event里执行什么 SQL以及用多少个线程去跑它就能模拟出特定形态的负载。5.2 一个实际案例单表点查压测假设你要模拟基于主键查询订单状态的业务并发基本都在做SELECT * FROM order_table WHERE order_id ?。你可以写这样一个脚本function thread_init(thread_id) -- 注意这里不是 C API脚本里的 db_conn 由 sysbench 运行时注入 end function event() local order_id math.random(1, 200000) local query string.format( SELECT status, amount FROM order_table WHERE order_id %d, order_id ) db_conn:query(query) end对应的执行命令sysbench /root/scripts/my_select.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordsbtest123 \ --mysql-dbyour_db \ --tables1 \ --table-size1 \ --threads32 \ --time120 \ --db-ps-modedisable \ run注意我这里的--tables1 --table-size1是故意设的因为自定义脚本的生产数据一般由你自己提前生成不用 sysbench 的 prepare 数据结构。你需要保证order_table在测试库里真实存在并且有 20 万行左右的数据否则随机查询的值可能大量落在表不存在的区域上导致大量空结果和实际业务不符。自定义脚本跑出来的结果和默认脚本最大的不同是你清楚每个 event 代表什么。默认脚本的 event 是一个读写事务包含好几个 SQL你的点查脚本的 event 就是一条点查 SQL。这个语义对应关系对于向团队解释压测结果极其重要。5.3 为什么我在脚本里尽量用随机数据而不是固定值写自定义脚本时有个常见错误为了省事把查询条件写死成一个常量比如WHERE statusSUCCESS。这样跑出来的结果会严重失真因为数据库缓存会把这一页数据一直留在缓冲池里每次查询都命中缓存I/O 完全压不出来。真实的业务条件值总是有分布的。所以我在脚本里会先定义一个分布范围再随机取样。就像上面的math.random(1, 200000)。这里推荐一个进阶玩法如果你的业务符合热点分布少数数据被高频访问可以用sysbench.rand来生成不同分布的数据。sysbench 内置了好几种随机分布函数重尾分布和正态分布的差异对数据库缓存命中率的影响非常显著。一段带分布控制的示例function event() local order_id local r sysbench.rand.uniform(1, 100) if r 80 then order_id sysbench.rand.uniform(1, 5000) -- 80% 的请求落在小范围热点 else order_id sysbench.rand.uniform(5001, 200000) -- 20% 的请求落在长尾 end db_conn:query(string.format( SELECT status, amount FROM order_table WHERE order_id %d, order_id )) end这样模拟出来的负载缓冲池命中率会更接近真实业务——大部分请求命中同一批热门订单页少量请求穿透到磁盘。我在某一次基于真实订单场景的压测里用这种分布跑出来的 QPS 和线上监控里的 QPS 曲线高度吻合而用默认均匀随机分布跑则严重偏低。这个经验后来一直被我当成自定义脚本必须做的一点来用。6. 我踩过的坑、误差来源以及怎么让结果可信压测最忌讳的是测了一堆数据但没法用。数字看起来很漂亮换个环境时间再跑一遍数据完全对不上。以下是我在这些年实际使用 sysbench 过程中踩过的坑和总结出的规避方法。6.1 断崖式 TPS 变化先别怪数据库检查这些有一次我在压一个数据库集群跑到第 40 秒左右 TPS 突然从 3000 掉到 800并且持续低频振动。我第一反应是数据库出了问题于是各种查慢查询、锁等待都没发现异常。后来开了一个新窗口看 sysbench 所在机器的负载才发现压测机本身 CPU 已经 100%。办坏事的是测试机而不是数据库。sysbench 是一个单机工具它所有线程都跑在发起压测的这台机器上。线程数开太高时测试机自己的 CPU 会先饱和导致它造压力的能力跟不上TPS 自然掉下去。从那以后我压测前会先确认测试机至少有 4 个空闲核心或者把线程数控制在测试机核数的两倍以内。如果你发现异常第一件事先看压测机的 CPU 和内存再看数据库端这个排错顺序帮我省了大量时间。6.2 内存和缓存对压测结果的干扰数据库压测时MySQL 的innodb_buffer_pool_size会很大程度影响你的 TPS。同样的压测命令在缓冲池只有 1G 和 8G 的实例上跑出来的结果差异可能在一倍以上。这不是 sysbench 的问题而是数据库本来就该有缓存能力。所以我做系统性能基准时一般会把缓冲池调到合理大小比如环境总内存的 50% 到 60%再做压测。相对地如果我想压的是磁盘 I/O 能力而不是缓存命中能力我会故意调小innodb_buffer_pool_size或者让测试数据量远大于缓冲池。比如--table-size2000000这样数据总大小远超过内存查询就会真正打到磁盘跑出的 TPS 才代表冷数据场景下的能力。6.3 时钟与误报sysbench 不背的锅压力测试过程中如果服务器开启了 NTP 时间同步且时间跳跃幅度比较大会导致 sysbench 的计时和输出数据出现假波动。一次压测中我明明看到 TPS 报表非常稳定结果某个 10 秒间隔的中间报告突然中断了几秒整体时间线也乱了。查下来发现是 NTP 在校时。后来我做长时间压测时会临时停止 NTP 同步或者接受这种轻微抖动在结果分析时剔除明显异常的中间报告。另一个被忽略的问题是ignored errors。sysbench 跑完会输出ignored errors默认情况下它会把一些可忽略的数据库错误吞掉不中断压力测试。如果你的脚本里有主键冲突、死锁重试这类情况ignored errors会大于 0。我要提醒的是压测报告里 TPS 归 TPS、ignored errors 归 ignored errors不要视而不见。如果 errors 占事务比例超过 1%我会认为这轮压测结果不可信因为错误会产生锁等待、回滚降低整体 TPS这个数字不能代表系统正常能力。我自己的判断标准是压测开始前先跑一个 30 秒的短测试确认ignored errors: 0。如果从第一轮开始就有大量错误说明账号权限、表结构或者参数没配对不适合急着拉长测试时间。6.4 怎么让压测结果经得起推敲多轮 标准差最后说一下“可信度工程”。我不管做哪个环境、哪个模块的压测都会重复跑至少三到五轮然后取平均值和中位数来对比。关键是第二轮开始之前要有冷却时间让数据库缓冲池和内存状态回到一个相对正常的位置。我一般是每轮之间间隔 30 秒到 1 分钟长压测间隔更长。记录结果时我用的格式是第1轮 TPS/95ms: 3278 / 42ms 第2轮 TPS/95ms: 3301 / 41ms 第3轮 TPS/95ms: 3256 / 44ms 平均值: 3278波动范围: -0.7% ~ 0.7%如果某轮结果突然和其他几轮差异超过 10%我不会直接删掉它而是先排查那轮跑的时候有没有其他任务在抢资源。测试环境里跑着定时备份、日志压缩、监控抓包这些任务都会让某一轮数据异常。把原因找出来再重跑比单纯拿多个数字取均值要严谨得多。还有一个小技巧我把 sysbench 的中间报告--report-interval产生的那些都存到日志里而不仅仅是最后汇总。因为最后汇总只能看到全局平均值中间报告却能看出性能变化曲线。如果前 30 秒 TPS 稳定在 3000后 30 秒降到 2000那和 60 秒平均值 2500 是完全不同的两种故事。后者可能意味着缓冲池被撑满、磁盘 I/O 开始介入或者数据库内存分配触发了 swap。这些细节如果不看中间报告是永远发现不了的。sysbench 不是那种装好后跑完一条命令就能收工的工具它的真正价值在于你理解它每一层参数的含义以及能把压测结果和系统资源关联起来解释。我自己现在做任何服务器的基准验收时第一轮一定用固定的cpu --threads4 --time30快速确认硬件基础第二轮用默认oltp_read_write做一个能横向对比的参考值后面按业务需求写自定义 Lua 脚本做深入压测。这个流程跑了很多台机器数据一直稳定也方便跟往年记录做对比。如果你刚开始接触 sysbench建议先把我前面说的 CPU 和内存测试跑熟再进阶到数据库压测别一上来就追求高并发——先把一两个指标的为什么弄明白比刷高数字有用得多。 
长河君 · 2026/10/13 12:20:46 · 阅读 1.2k sysbench压测实战：CPU内存基准与MySQL读写压测
sysbench 这个压力测试工具我前后用了快十年。从最早拿它压本机 CPU、内存带宽到后来专门用来做 MySQL 的读写基准验证它在我的工具箱里一直是参数直白、行为可预期的存在。现在的压测工具多了不少有图形化的、有出报告特别漂亮的但我做上架前验收、调优前后对比、容量评估这类事情时还是会第一时间掏出 sysbench。这篇文章不是一个命令手册的翻译而是我多年实测下来的经验总结。我会讲清楚它到底能压什么、每条参数背后的含义、输出数据怎么读以及最重要的——一个完整的 MySQL 读写压测应该怎么做。内容对刚接触服务器性能测试的新手友好也能让已经用过一段时间、但只停留在跑个默认 cpu 测试阶段的人真正进阶。1. 为什么压测我还是会掏出 sysbench 而不是更花哨的工具先说结论sysbench 的价值在于它的覆盖面广和行为可预期。它不是一个只盯着数据库的压测工具而是一个通用系统基准测试工具。CPU、内存、文件 I/O、线程调度、互斥锁再到关系型数据库的 OLTP 基准全都能测。我经常在一个新服务器上用它五分钟内先跑完 CPU 和内存基准确认硬件没有明显问题然后再进入数据库层面的压测。一个 Jenkins 任务调用的就是同一套命令跑进 CI 后它的稳定性和输出可解析性比那些仪表盘华丽的工具强得多。很多人会问压数据库我用 mysqlslap 或者 pgbench 不就行了确实行但有一个区别。sysbench 的 OLTP 脚本本质是用 Lua 写的、自带事务编排逻辑的一套模拟协议它模拟的是多个客户端会话持续执行增删改查并提交事务的业务负载而不是像 mysqlslap 那样单纯并发跑几条 SQL。更关键的是sysbench 支持Lua 脚本自定义。你可以按自己的业务表结构去造数据、去写查询语句而不是被困在默认的几条 SQL 里。这一条就让它比很多专用工具灵活。我归纳了一下平时最常用的场景场景使用模块我一般看的关键指标新到货服务器的 CPU 性能验证cpuevents per second内存带宽与延迟粗检memory吞吐量 MB/s延迟分位磁盘/云盘的裸性能测试fileioIOPS 与延迟分位云服务器连续多轮跑分对比cpumemory多轮结果稳定性数据库读写与事务能力评估oltp_read_write等TPS、QPS、延迟分位SQL 脚本/业务流改造验证自定义 Lua按具体业务定义成功率从这张表也能看出来sysbench 在系统级基准和数据库级压力两个层面都站得住。这是很多工具做不到的因为它们要么只能压 CPU要么只能压 SQL。另外我比较看重的一点是它的跨版本稳定性。我最早用的 0.4到后来的 1.0再到现在的 1.1核心参数的命名和输出格式基本延续了下来。这意味着我五年前写的压测脚本现在只需要改极少的地方就能继续用。做性能测试最怕的就是工具版本一换、参数全变导致历史数据没法对比。sysbench 在这方面给了我很大的安全感。2. 装好之后第一件事跑通 sysbench 自带的 cpu 和 memory 基准sysbench 的安装没有太多可说的但我还是想提醒一个事不要把发行版自带的旧版 sysbench 当成最终版本直接用。有些老系统的源里还是 0.4 甚至更早的版本它的参数体系和新版差得很大。你搜网上教程的时候如果发现命令写的是--testcpu这种老格式那大概率是旧版。我建议直接用新版自己编译也不麻烦。2.1 安装中的两个实际注意点在新一点的 Debian/Ubuntu 上用apt install sysbenchCentOS/Rocky 上用dnf install sysbench通常都能拿到 1.0 以后的版本。但这些发行版自带包可能不是最新修复版如果你对某些 OLTP 脚本的细节行为有要求我更推荐源码安装curl -L -o sysbench.tar.gz https://github.com/akopytov/sysbench/archive/refs/tags/1.1.0.tar.gz tar xf sysbench.tar.gz cd sysbench-1.1.0 ./autogen.sh ./configure --with-mysql make -j$(nproc) sudo make install这里有个细节configure时我习惯加上--with-mysql这样会同时编译出数据库压测所需的oltp_*.lua脚本和驱动。如果你只做 CPU、磁盘类的测试不加 MySQL 支持也行但数据库压测那章的内容就做不了了。编译前机器上需要有libmysqlclient-dev这类开发包缺了它会直接提示找不到 mysql.h。装完之后务必确认一下版本我一般这么看sysbench --version如果输出sysbench 1.1.0脚本目录在/usr/local/share/sysbench/下能找到oltp_read_write.lua等文件说明装得没问题。这个脚本目录路径很关键后面跑数据库压测时你总会跟它打交道。2.2 首次压测看清 CPU 输出中的这几个数字装好后我建议新手跑的第一个测试不是数据库而是 CPU 基准。因为它不需要任何前置准备一条命令见真章sysbench cpu --threads4 --time30 --events0 run跑出来的结果里最关键的是events per second它代表每秒事件数。sysbench 的cpu模块做的事很简单每个线程循环计算指定范围内的质数每算完一轮记一个 event。所以这个数字越大说明 CPU 在这个特定计算模型下跑得越快。这块我给一个非常实用的经验连续跑三到五次看事件数是否稳定。如果数值上下波动超过 3% 到 5%先别急着下结论要确认机器的频率策略。现在的服务器 CPU 有睿频机制压测前系统负载低时前几秒频率可能没拉满容易让人误判性能。我一般会在正式测试前先跑一个--time5的预热让频率和温度都稳定下来然后再用--time60做正式记录。顺带一提--events0表示不限制总事件数只按时间停止。--time30则是最大运行 30 秒。很多教程会漏掉--events0导致压测在某个固定事件数下提前结束数据不够充分。你要根据场景自己选但我在做系统级测试时更常用按时间结束的模式。2.3 内存测试的误区它测的不是容量而是搬运速度内存测试的常见误解是觉得它能测试内存容量是否正确、ECC 是否生效。实际上sysbench 的memory模块做的是读写内存块操作的吞吐和延迟本质是测试内存带宽和访问延迟不是测试容量。我常用的内存测试命令sysbench memory --threads2 --memory-block-size1M --memory-total-size10G --memory-operread run sysbench memory --threads2 --memory-block-size1M --memory-total-size10G --memory-operwrite run这里需要解释两个参数。--memory-block-size是每次操作搬运的数据块大小块越大越能体现连续内存的带宽--memory-total-size是所有线程总共搬运的数据量10G是我在内存大于 16G 的机器上常用的量级。数据量太小容易受缓存影响数据量太大又会让测试时间变得过长。读操作和写操作要分开测因为大部分场景下读吞吐会比写快。输出里的Total operations、MiB transferred、MB/sec这三个值比较关键其中MB/sec就是内存吞吐。做多线程测试时注意--threads不要无脑开到几十甚至上百因为内存控制器本来就能并行处理一定数量的请求线程数太多反而会让锁竞争干扰测试目标。我在单路服务器上的经验值是 CPU 核数的一半到两倍之间别超过太多。3. 数据库压测的关键看懂输出、配好参数、改对自己的脚本如果说 CPU 和内存测试只是热身那 sysbench 真正让人又爱又恨的地方是它的数据库压测。爱是因为它足够强大恨是因为参数太多输出数据结构复杂稍不留神就跑出不具参考意义的数据。跑数据库压测之前先理解它的整体三段式流程prepare阶段建表、插入指定数量的测试行 run阶段真正并发执行压测脚本 cleanup阶段清理掉测试表这三阶段用的基本是同一个脚本入口靠prepare、run、cleanup三个子命令区分。我第一次用的时候没搞清这个逻辑直接跑run结果报错说表不存在后来才知道要先prepare。现在倒觉得这个三段式设计很干净它把造数据跑压力收尾彻底分开了特别适合自动化集成。3.1 核心参数对照表一眼看清每个参数的用途我把平时最常用的参数整理成一张表方便你查参数含义我的常用值备注--threadsN并发线程数16/32/64不是越大越好见下文--eventsN总事件数上限00 表示不限制按时间跑--timeN最大运行秒数60/120现场压测我常用 300--report-intervalN每 N 秒打印一次中间统计10用于观察波动--rateN限制每秒事件数不设置主要用于限速模拟--tablesN测试表数量16多表更贴近真实业务--table-sizeN每张表的行数100000行数过少缓存干扰大--mysql-host/--mysql-port数据库地址端口-本机测试也要写走 TCP--mysql-user/--mysql-password账号密码-建议专用账号--mysql-db目标库sbtest需要提前创建--db-drivermysql驱动类型mysql压 pg 则写 pgsql--db-ps-modedisableSQL 预处理开关disable见下文解释这里我得专门展开说一个参数--db-ps-modedisable。默认情况下 sysbench 会使用 MySQL 预处理语句prepared statement这能让 SQL 执行计划在多次执行中被复用缩短单条 SQL 的耗时。但如果你压测的目标是排查慢查询、评估真实业务的 SQL 解析与执行全链路成本预处理会掩盖一部分开销。我习惯在 OLTP 基准中用disable把 SQL 准备过程也纳入压力范围这样跑出来的结果更贴近一个不懂复用执行计划的普通业务连接的真实表现。当然如果你想模拟大量使用 ORM 预处理语句的系统那就保持默认的自动模式。这个选择会直接影响你的 TPS 数据对比测试时前后要一致。3.2 输出数据读法TPS、QPS、百分位延迟各有各的读法第一次跑 sysbench 数据库压测的时候很多人会懵屏幕上既有一堆read/write的吞吐数据又有一个延迟汇总还时不时刷新中间报告。完整结果里最核心的是两部分SQL statistics: queries performed: read: 425600 write: 121600 other: 51200 total: 598400 transactions: 6400 (1280.00 per sec.) queries: 85120 (17024.00 per sec.) ignored errors: 0 (0.00 per sec.) reconnects: 0 (0.00 per sec.) Latency (ms): min: 23.45 avg: 127.38 max: 984.22 95th percentile: 412.76 sum: 815232.11第一行的transactions后面的括号数字就是TPS即每秒事务数。第二行的queries括号数字是QPS。这两个数字是整个压测报告最核心的指标。事务在这里指一组完整的读写 SQL 组合一次事务可能包含多条 SQL所以 QPS 一般远高于 TPS。延迟统计里avg是所有事务的平均耗时95th percentile表示有 95% 的事务延迟低于这个数。我特别建议你先看95th percentile而不是avg因为数据库偶尔会出现长尾请求把平均值拉高但 95 分位能更真实反映绝大多数请求体感多快。比如上面的结果里 avg 是 127ms看起来还行但 95 分位已经到 412ms说明尾部请求有明显卡顿。这种数据如果只看 avg你很可能会误判系统性能。中间过程报告来自--report-interval10这类参数。它能在跑的过程中每 10 秒刷新一次 tps、qps、延迟数据。做现场故障排查时我特别依赖这个输出它能让我看到压力慢慢上来时性能是不是线性变化还是到了某个时间点突然断崖式下跌——后者往往意味着发生了锁等待、连接耗尽或内存交换。3.3 为什么我不建议无脑把 --threads 拉到上百有个非常经典的坑把--threads从 16 翻到 64TPS 可能涨了但延迟跟着也涨了再翻到 128TPS 反而可能下降。原因很简单并发线程数超过数据库处理能力后请求开始排队而不是并行处理。排队时间越长延迟越高TPS 不再增长甚至因为资源竞争而下滑。我做容量评估时一般这样测试从 8 个线程开始按照 16、32、64、128 的梯度依次跑每轮跑完记录 TPS 和 95 分位延迟然后画一条并发数—TPS的曲线。曲线上最后那个TPS 增长幅度小于 5% 的线程数基本就是这个系统的建议并发上限。这个值对后续配置连接池大小非常有参考价值——我见过不少团队的连接池配了 200 个连接实际压测显示 64 连接时性价比最高200 连接只是让线程全部堆积在数据库侧。4. 一次完整的 MySQL 读写混合压测应该怎么做前面讲了不少原理现在来一次完整的实战。这一节我按自己常用的标准流程来走你可以直接当模板用。4.1 准备压测库、账号与表结构先在 MySQL 里创建数据库和账号这一步很多人会漏掉。sysbench 的prepare不会帮你创建数据库只会建表。我用的一套标准准备 SQL 是CREATE DATABASE IF NOT EXISTS sbtest CHARACTER SET utf8mb4; CREATE USER IF NOT EXISTS sbtest% IDENTIFIED BY sbtest123; GRANT ALL PRIVILEGES ON sbtest.* TO sbtest%; FLUSH PRIVILEGES;为什么要单独建一个专用账号因为压测时会产生大量连接如果复用业务的正式账号一来可能触发权限审计告警二来错误日志里会被压测报错刷屏影响你对真实问题的判断。专用的 sbtest 账号用完随时可以清理权限也限制在这个库内风险可控。然后跑prepare生成 16 张表每张 10 万行sysbench /usr/local/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordsbtest123 \ --mysql-dbsbtest \ --tables16 \ --table-size100000 \ --threads16 \ prepare这条路走到一半最容易出的问题有几种提示Table sbtest.sbtest1 doesnt exist说明你还没跑过 prepare提示权限不足说明账号授权时没给到对应库卡在插入很久没反应多半是表数量和数据行数设得太大或者磁盘刷脏页很慢。我自己的经验是压测前先跑通一次小数据量的全过程。比如先用--tables4 --table-size10000跑一遍 prepare→run→cleanup确认脚本和参数没问题再上正式容量。这能省下大量排错时间因为你不会知道是脚本问题还是资源瓶颈。4.2 正式压测长时间比短时间更能说明问题我见过很多人在压测时用--time10这是非常不推荐的做法。10 秒太短数据库的缓冲池都还没热起来CPU 频率也未必稳定跑出来的数据只能算误差。我自己在现场做基准测试时最少用 60 秒正式记录用 120 秒排查性能波动时会跑到 300 秒。正式读写混合压测命令sysbench /usr/local/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordsbtest123 \ --mysql-dbsbtest \ --tables16 \ --table-size100000 \ --threads32 \ --time120 \ --report-interval10 \ --db-ps-modedisable \ run跑的时候我习惯在旁边开一个终端用top或者htop观察 CPU 和内存再开另一个窗口看 MySQL 的show processlist。为什么要看这些因为 sysbench 跑出来的数字再漂亮也要结合服务器资源使用情况才能下结论。比如 TPS 只有 500CPU 利用率却已经 100%说明瓶颈可能在 CPU 计算而不是数据库层面如果 TPS 使用 32 线程和 16 线程差不多CPU 也没吃满那就要怀疑是不是锁等待或者 IO 卡顿。我还会顺带看 MySQL 的线程状态。如果 processlist 里大量线程卡在statistics或Sending data那通常是单条 SQL 性能差导致的如果大量线程卡在Updating或update则更可能是写锁竞争。这些东西 sysbench 本身并不会直接告诉你需要你人肉关联来看这也正是实战二字比跑命令更值钱的地方。4.3 压完怎么清理数据压测完成后不要忘了清理环境。虽说留着测试表问题也不大但如果你是在生产库旁边开的临时环境或者压测完后要继续装监控系统测试表会污染后续指标。清理命令很简单sysbench /usr/local/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordsbtest123 \ --mysql-dbsbtest \ --tables16 \ --table-size100000 \ cleanup清理之后确认一下SHOW TABLES;是否为空。有些版本在清理过程中如果遇到连接中断可能会残留部分表需要手动DROP TABLE。这个细节很小但对自动化脚本的幂等性影响很大——一个重新执行清理会报错的脚本集成到 CI 里会非常难受。5. 自定义 Lua 压测脚本让 sysbench 真正贴合业务默认的oltp_read_write是一个通用的 TPCC 风格基准简单好用但它和你的真实业务相比SQL 模型差异可能非常大。比如你的业务绝大部分是单条主键查询很少写再比如你有一个报表系统查询时间很长、并发也不高。用默认脚本压出来的数据只能代表sysbench 模拟的通用负载不能代表你的业务跑在这个机器上的表现。所以真正会用 sysbench 的人都会改脚本。5.1 脚本结构骨架三件事一个最小可用的 Lua 脚本长这样。我习惯把它放在/root/scripts/或者项目目录下文件名自取比如my_select.luafunction thread_init(thread_id) -- 每个线程开始时执行一次在这里初始化专用连接或变量 end function thread_done(thread_id) -- 线程结束时执行一般用来关闭连接 end function event() -- 这是核心函数每触发一个 event 就执行一次 -- 一般在这里构造 SQL 并执行 local table_name sbtest1 local k math.random(1, 100000) local rs db_conn:query(SELECT c FROM .. table_name .. WHERE id .. k) endsysbench 执行 Lua 脚本的机制是每个 worker 线程在初始化时调用thread_init然后不断循环调用event直到到达期望的--events总数或--time时间上限。event每执行一次就算一个 event。所以events per second实际上就是每秒执行了多少次event。理解这个结构之后你就会明白自定义脚本的本质是你只要控制event里执行什么 SQL以及用多少个线程去跑它就能模拟出特定形态的负载。5.2 一个实际案例单表点查压测假设你要模拟基于主键查询订单状态的业务并发基本都在做SELECT * FROM order_table WHERE order_id ?。你可以写这样一个脚本function thread_init(thread_id) -- 注意这里不是 C API脚本里的 db_conn 由 sysbench 运行时注入 end function event() local order_id math.random(1, 200000) local query string.format( SELECT status, amount FROM order_table WHERE order_id %d, order_id ) db_conn:query(query) end对应的执行命令sysbench /root/scripts/my_select.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordsbtest123 \ --mysql-dbyour_db \ --tables1 \ --table-size1 \ --threads32 \ --time120 \ --db-ps-modedisable \ run注意我这里的--tables1 --table-size1是故意设的因为自定义脚本的生产数据一般由你自己提前生成不用 sysbench 的 prepare 数据结构。你需要保证order_table在测试库里真实存在并且有 20 万行左右的数据否则随机查询的值可能大量落在表不存在的区域上导致大量空结果和实际业务不符。自定义脚本跑出来的结果和默认脚本最大的不同是你清楚每个 event 代表什么。默认脚本的 event 是一个读写事务包含好几个 SQL你的点查脚本的 event 就是一条点查 SQL。这个语义对应关系对于向团队解释压测结果极其重要。5.3 为什么我在脚本里尽量用随机数据而不是固定值写自定义脚本时有个常见错误为了省事把查询条件写死成一个常量比如WHERE statusSUCCESS。这样跑出来的结果会严重失真因为数据库缓存会把这一页数据一直留在缓冲池里每次查询都命中缓存I/O 完全压不出来。真实的业务条件值总是有分布的。所以我在脚本里会先定义一个分布范围再随机取样。就像上面的math.random(1, 200000)。这里推荐一个进阶玩法如果你的业务符合热点分布少数数据被高频访问可以用sysbench.rand来生成不同分布的数据。sysbench 内置了好几种随机分布函数重尾分布和正态分布的差异对数据库缓存命中率的影响非常显著。一段带分布控制的示例function event() local order_id local r sysbench.rand.uniform(1, 100) if r 80 then order_id sysbench.rand.uniform(1, 5000) -- 80% 的请求落在小范围热点 else order_id sysbench.rand.uniform(5001, 200000) -- 20% 的请求落在长尾 end db_conn:query(string.format( SELECT status, amount FROM order_table WHERE order_id %d, order_id )) end这样模拟出来的负载缓冲池命中率会更接近真实业务——大部分请求命中同一批热门订单页少量请求穿透到磁盘。我在某一次基于真实订单场景的压测里用这种分布跑出来的 QPS 和线上监控里的 QPS 曲线高度吻合而用默认均匀随机分布跑则严重偏低。这个经验后来一直被我当成自定义脚本必须做的一点来用。6. 我踩过的坑、误差来源以及怎么让结果可信压测最忌讳的是测了一堆数据但没法用。数字看起来很漂亮换个环境时间再跑一遍数据完全对不上。以下是我在这些年实际使用 sysbench 过程中踩过的坑和总结出的规避方法。6.1 断崖式 TPS 变化先别怪数据库检查这些有一次我在压一个数据库集群跑到第 40 秒左右 TPS 突然从 3000 掉到 800并且持续低频振动。我第一反应是数据库出了问题于是各种查慢查询、锁等待都没发现异常。后来开了一个新窗口看 sysbench 所在机器的负载才发现压测机本身 CPU 已经 100%。办坏事的是测试机而不是数据库。sysbench 是一个单机工具它所有线程都跑在发起压测的这台机器上。线程数开太高时测试机自己的 CPU 会先饱和导致它造压力的能力跟不上TPS 自然掉下去。从那以后我压测前会先确认测试机至少有 4 个空闲核心或者把线程数控制在测试机核数的两倍以内。如果你发现异常第一件事先看压测机的 CPU 和内存再看数据库端这个排错顺序帮我省了大量时间。6.2 内存和缓存对压测结果的干扰数据库压测时MySQL 的innodb_buffer_pool_size会很大程度影响你的 TPS。同样的压测命令在缓冲池只有 1G 和 8G 的实例上跑出来的结果差异可能在一倍以上。这不是 sysbench 的问题而是数据库本来就该有缓存能力。所以我做系统性能基准时一般会把缓冲池调到合理大小比如环境总内存的 50% 到 60%再做压测。相对地如果我想压的是磁盘 I/O 能力而不是缓存命中能力我会故意调小innodb_buffer_pool_size或者让测试数据量远大于缓冲池。比如--table-size2000000这样数据总大小远超过内存查询就会真正打到磁盘跑出的 TPS 才代表冷数据场景下的能力。6.3 时钟与误报sysbench 不背的锅压力测试过程中如果服务器开启了 NTP 时间同步且时间跳跃幅度比较大会导致 sysbench 的计时和输出数据出现假波动。一次压测中我明明看到 TPS 报表非常稳定结果某个 10 秒间隔的中间报告突然中断了几秒整体时间线也乱了。查下来发现是 NTP 在校时。后来我做长时间压测时会临时停止 NTP 同步或者接受这种轻微抖动在结果分析时剔除明显异常的中间报告。另一个被忽略的问题是ignored errors。sysbench 跑完会输出ignored errors默认情况下它会把一些可忽略的数据库错误吞掉不中断压力测试。如果你的脚本里有主键冲突、死锁重试这类情况ignored errors会大于 0。我要提醒的是压测报告里 TPS 归 TPS、ignored errors 归 ignored errors不要视而不见。如果 errors 占事务比例超过 1%我会认为这轮压测结果不可信因为错误会产生锁等待、回滚降低整体 TPS这个数字不能代表系统正常能力。我自己的判断标准是压测开始前先跑一个 30 秒的短测试确认ignored errors: 0。如果从第一轮开始就有大量错误说明账号权限、表结构或者参数没配对不适合急着拉长测试时间。6.4 怎么让压测结果经得起推敲多轮 标准差最后说一下“可信度工程”。我不管做哪个环境、哪个模块的压测都会重复跑至少三到五轮然后取平均值和中位数来对比。关键是第二轮开始之前要有冷却时间让数据库缓冲池和内存状态回到一个相对正常的位置。我一般是每轮之间间隔 30 秒到 1 分钟长压测间隔更长。记录结果时我用的格式是第1轮 TPS/95ms: 3278 / 42ms 第2轮 TPS/95ms: 3301 / 41ms 第3轮 TPS/95ms: 3256 / 44ms 平均值: 3278波动范围: -0.7% ~ 0.7%如果某轮结果突然和其他几轮差异超过 10%我不会直接删掉它而是先排查那轮跑的时候有没有其他任务在抢资源。测试环境里跑着定时备份、日志压缩、监控抓包这些任务都会让某一轮数据异常。把原因找出来再重跑比单纯拿多个数字取均值要严谨得多。还有一个小技巧我把 sysbench 的中间报告--report-interval产生的那些都存到日志里而不仅仅是最后汇总。因为最后汇总只能看到全局平均值中间报告却能看出性能变化曲线。如果前 30 秒 TPS 稳定在 3000后 30 秒降到 2000那和 60 秒平均值 2500 是完全不同的两种故事。后者可能意味着缓冲池被撑满、磁盘 I/O 开始介入或者数据库内存分配触发了 swap。这些细节如果不看中间报告是永远发现不了的。sysbench 不是那种装好后跑完一条命令就能收工的工具它的真正价值在于你理解它每一层参数的含义以及能把压测结果和系统资源关联起来解释。我自己现在做任何服务器的基准验收时第一轮一定用固定的cpu --threads4 --time30快速确认硬件基础第二轮用默认oltp_read_write做一个能横向对比的参考值后面按业务需求写自定义 Lua 脚本做深入压测。这个流程跑了很多台机器数据一直稳定也方便跟往年记录做对比。如果你刚开始接触 sysbench建议先把我前面说的 CPU 和内存测试跑熟再进阶到数据库压测别一上来就追求高并发——先把一两个指标的为什么弄明白比刷高数字有用得多。