mysql性能基准测试工具推荐 使用sysbench进行压力测试实战案例|Duuu笔记
sysbench 是 MySQL 压测的事实工业标准，因其 Lua 脚本灵活性、指标可对标 SLO 且被主流云厂商广泛采用；必须源码编译以适配 MySQL 8.0+ 认证机制；prepare 卡住多因权限、网络或 max_allowed_packet 不足；不同 Lua 脚本事务结构差异大，直接影响瓶颈定位；需按目标调参，否则测不到真实瓶颈。
sysbench 是当前 MySQL 压测最稳、最可控的选择
不是“之一”，而是事实上的工业级标准：它被 Percona、阿里云 PolarDB、腾讯云 TDSQL 等大量生产环境用于上线前容量评估和故障复现。相比 tpcc-
mysql
或 mysqlslap，
sysbench
的 Lua 脚本机制让它能灵活模拟真实业务读写比例、事务结构和热点分布，且结果指标（TPS/QPS/95% latency）可直接对标 SLO。
安装必须走源码编译，尤其在新版 MySQL 8.0+ 或自建集群场景
包管理器装的
sysbench
（如
yum install sysbench
）往往链接旧版 MySQL client lib，连接 MySQL 8.0+ 时容易报
Authentication plugin 'caching_sha2_password' cannot be loaded
或直接段错误。源码编译能精准控制依赖版本。
先装对的开发库：
sudo apt install libmysqlclient-dev libssl-dev
（Ubuntu/Debian）或
sudo yum install mysql-devel openssl-devel
（CentOS/RHEL）
务必指定 MySQL 路径（尤其当 MySQL 是 tar.gz 自定义部署）：
./configure --with-mysql-includes=/usr/local/mysql/include --with-mysql-libs=/usr/local/mysql/lib
编译后验证驱动是否生效：
sysbench --help | grep mysql
应显示
mysql
在 supported drivers 列表中
prepare 阶段卡住或报错，大概率是权限或网络配置问题
sysbench ... prepare
不只是建表，还会执行大量 INSERT，失败时错误信息常被掩盖。常见现象是命令无响应、日志里只有
FATAL: failed to execute MySQL query
，但没具体 SQL。
Action Figure AI
借助Action Figure AI的先进技术，瞬间将照片转化为定制动作人偶。
下载
确认账号有
CREATE
、
INSERT
、
SELECT
、
INDEX
权限，且 host 匹配（别用
'user'@'%'
却连本地
127.0.0.1
）
检查 MySQL 的
max_allowed_packet
是否太小（默认 4MB），
sysbench
插入百万行时易触发
Packets larger than max_allowed_packet are not allowed
若用 ProxySQL 或中间件，确认其未拦截
PREPARE
或
EXECUTE
语句（某些版本会静默拒绝）
oltp_read_write.lua 和 oltp_point_select.lua 的行为差异远不止“读写比”
很多人以为换脚本只是改读写比例，实际它们的事务结构、索引使用方式、锁竞争强度完全不同——这直接影响你看到的瓶颈是 CPU、IO 还是锁等待。
oltp_read_write.lua
默认每事务含 10 条 SQL（包括 UPDATE、DELETE、INSERT），主键更新+二级索引维护压力大，容易暴露
innodb_buffer_pool_size
不足或
innodb_log_file_size
过小
oltp_point_select.lua
只做主键等值查询，几乎不写盘，压的是 Buffer Pool 命中率和 CPU 解析能力；若这里 latency 突增，优先查
innodb_buffer_pool_reads
是否飙升
别直接跑默认参数！比如
--tables=10 --table-size=1000000
生成 10GB 数据，但你的 buffer pool 才 2GB —— 结果全是物理读，测的不是 MySQL，是磁盘
真正难的不是跑起来，而是让
sysbench
测出你关心的那个瓶颈。比如想看高并发下死锁频率，就得关掉自动重试（加
--reconnect=off
），再盯着
SHOW ENGINE INNODB STATUS
里的 LATEST DETECTED DEADLOCK；想验证连接池效果，就得把
--threads
从 16 拉到 256，同时观察 MySQL 的
Threads_connected
和
Aborted_connects
。这些细节不调，数据再好看也没参考价值。
