评估一套MongoDB集群的真实性能，光看官方的宣传数字远远不够，必须借助基准测试工具在自己的硬件环境下跑出实际数据。mongodb-sysbench是MongoDB团队早期推出的一款基准测试工具，它改编自MySQL圈子里大名鼎鼎的sysbench，将底层存储引擎替换为MongoDB驱动，专门用来模拟键值型读写负载。这篇文章就从工具原理、安装部署、测试执行和结果解读四个方面，完整讲一遍它的使用方法。
一、mongodb-sysbench是什么，适合测什么场景
mongodb-sysbench的核心思想是模拟一个简单的键值存储负载。它会在指定的集合中写入一批文档，然后按照配置的比例混合执行插入、查询、更新等操作，统计每秒执行的事务数（TPS）和响应时间分布。由于它的操作模型非常简单，单条文档只有一个自定义字段加上一个大约13KB的blob字段，所以它测出来的数字更多反映的是MongoDB底层存储引擎和网络栈的极限能力，而不是复杂业务查询的真实表现。
这一点非常重要：mongodb-sysbench适合用来做存储引擎选型对比、硬件配置评估、不同版本之间的性能回归测试，比如对比MMAPv1与WiredTiger引擎的差异，或者评估SSD与机械盘在写密集负载下的差距。但如果你要测试的是复杂聚合查询、多表关联这类业务场景，它就不合适了，应该考虑YCSB或者自己写压测脚本。
与YCSB相比，mongodb-sysbench的模型更单一，配置更简单，跑出来的结果也更容易横向比较。YCSB提供了丰富的工作负载模板（A到F），适合模拟更贴近真实业务的读写比例，但配置项多、上手成本高。如果只是想快速摸一下服务器的底，mongodb-sysbench是更轻量的选择。
二、编译安装mongodb-sysbench
mongodb-sysbench的源码托管在GitHub上，需要手动编译安装。它依赖C语言编译环境和MongoDB C驱动，所以在编译之前要先准备好这些依赖。以Ubuntu为例，先安装基础工具：
sudo apt-get update sudo apt-get install -y git build-essential automake autoconf libtool pkg-config # 安装mongo-c-driver，建议1.x版本 git clone https://github.com/mongodb/mongo-c-driver.git cd mongo-c-driver git checkout 1.9.5 ./autogen.sh ./configure --prefix=/usr/local make && sudo make install sudo ldconfig
接着下载mongodb-sysbench源码并编译：
git clone https://github.com/tborgato/mongodb-sysbench.git cd mongodb-sysbench ./autogen.sh ./configure --with-mongoc=/usr/local make sudo make install
编译完成后，会在安装目录下生成可执行文件。可以通过sysbench --version验证是否安装成功。需要注意，如果编译时报找不到mongoc.h头文件，通常是mongo-c-driver没有安装到--with-mongoc指定的路径，检查一下pkg-config --cflags libmongoc-1.0的输出即可定位问题。另外，CentOS系列系统需要额外安装epel-release和对应的开发包，过程类似，只是包管理器命令换成yum或dnf。
三、执行基准测试并解读结果
mongodb-sysbench的用法和经典sysbench类似，分为prepare、run、cleanup三个阶段。prepare阶段负责往集合里灌入初始数据，run阶段执行真正的压力测试，cleanup阶段清理数据。一个完整的测试流程如下：
# 准备阶段：写入100万条测试数据，20个并发线程 sysbench \ --mongodb-host=127.0.0.1 \ --mongodb-port=27017 \ --mongodb-db=test \ --mongodb-collection=sysbench \ --number-of-documents=1000000 \ --number-of-threads=20 \ --doc-size=13 \ run prepare # 正式压测：读写混合负载，持续5分钟 sysbench \ --mongodb-host=127.0.0.1 \ --mongodb-port=27017 \ --mongodb-db=test \ --mongodb-collection=sysbench \ --number-of-documents=1000000 \ --number-of-threads=20 \ --doc-size=13 \ --max-time=300 \ --max-requests=0 \ run
几个关键参数需要理解清楚。--number-of-documents决定数据集大小，直接影响缓存命中率，数据集远大于内存时测的是磁盘IO能力，小于内存时测的是CPU和内存带宽。--number-of-threads模拟并发客户端数，建议从低到高逐步增加，观察TPS曲线是否已经饱和。--doc-size控制文档大小，默认13KB左右，可以根据实际业务调整。--max-requests=0表示不限请求数，配合--max-time控制测试时长。
测试结束后，工具会输出一份统计报告，重点关注这几个指标：TPS（每秒事务数）反映整体吞吐能力；平均响应时间和95%、99%分位延迟反映长尾表现；读写操作的分项统计可以看出负载是否均衡。做对比测试时，务必保证每次只有单一变量，比如固定数据集大小、固定文档尺寸，只调整线程数或存储引擎，否则结果没有可比性。
还有一个容易被忽视的细节：压测机和被测MongoDB服务器最好分开部署。如果压测程序和数据库跑在同一台机器上，压测本身消耗的CPU会挤占数据库资源，导致测出来的数据偏低。同时每轮测试之间要等待系统完全空闲（可以用mongostat观察）再开始下一轮，避免上一轮的脏页刷盘影响结果。
四、把基准测试变成可复用的评估流程
单次测试的数据意义有限，真正有价值的是建立一套标准化的测试流程。建议的做法是：准备一套固定的测试脚本，覆盖小数据集（全内存）和大数据集（超内存）两种场景，线程数按1、4、8、16、32、64递增，每个组合至少跑三分钟并重复三次取平均值，把所有结果记录到表格中，形成一份硬件或版本的性能基线。
拿到基线数据后，后续无论是升级MongoDB版本、更换存储引擎配置（比如调整WiredTiger的cacheSizeGB）、还是扩容硬件，都可以用同一套脚本重新跑一遍，与基线对比就能量化改动带来的收益或退化。结合mongostat、iostat等监控工具在测试期间同步采集系统指标，还能进一步定位瓶颈到底在CPU、磁盘还是网络。这样一套流程建立起来之后，容量规划和性能调优就不再是凭感觉拍脑袋，而是有数据支撑的工程决策。
mongodb-sysbenchMongoDB基准测试MongoDB性能测试工具修改时间：2026-09-11 07:26:29