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。
- 确认账号有
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。这些细节不调，数据再好看也没参考价值。
