sysbench 是 mysql 压测首选工具，因其测试模型贴近真实负载、能隔离数据库层性能、原生支持典型事务场景且比 mysqlslap 和手写脚本更可控。
为什么 Sysbench 是 MySQL 压测首选工具
因为它的测试模型贴近真实负载，且能隔离数据库层性能，不被应用框架或网络干扰。它原生支持 oltp_read_write、oltp_point_select 等典型事务场景，不像 mysqlslap 那样只跑简单 SQL 拼接，也比手写脚本更可控。
容易踩的坑：sysbench 默认用 Lua 脚本驱动，但很多人直接改参数却忽略脚本版本兼容性——比如 sysbench 1.0+ 的 --tables 和旧版含义不同；另外，它不校验数据一致性，压测完得自己用 checksum table 对比。
初始化测试库和表时的关键参数
别直接跑 sysbench prepare 就完事。表结构、索引、引擎类型直接影响结果可比性。
-
--table-size=100000控制单表行数，太小（如 1k）会导致缓存命中率虚高，掩盖 I/O 瓶颈 -
--tables=16建议设为 CPU 核心数的 2–4 倍，避免锁争用集中在少数表上 - 默认用
InnoDB，但要确认innodb_buffer_pool_size已调大（至少占物理内存 50%），否则大量磁盘读会拉低 TPS - 务必加
--db-driver=mysql，否则可能误走pgsql分支导致连接失败
运行压测时必须调整的并发与时间策略
盲目加大 --threads 只会让结果失真。MySQL 在高并发下容易触发锁等待、CPU 上下文切换激增，TPS 反而下降。
实操建议：
- 从
--threads=4开始，每次翻倍（4→8→16→32），观察queries per second是否线性增长；一旦增速明显放缓，就接近当前配置瓶颈点 -
--time=60是底线，少于 30 秒的测试波动太大；但超过 300 秒需关注slow log是否有堆积 - 加
--report-interval=10实时看每 10 秒吞吐变化，能快速识别是否卡在某次长事务或锁等待 - 别用
--rate=0（无限制速率），它会让 QPS 瞬间冲高然后崩，应设为合理上限如--rate=1000
怎么看压测结果才不算被数字骗
只盯着 transactions: 后面那个总数是危险的。真正要拆开看的是 read/write/other 分布、latency 的 95% 和 99% 分位值，以及 errors 是否为 0。
常见误判：
- TPS 很高但
99th percentile latency > 500ms：说明尾部延迟严重，对用户感知极差 -
reconnects:非零：大概率是max_connections不够或连接池超时设置过短 -
total time:远大于--time：说明有大量请求排队，实际并发没打满 - 对比不同环境时，必须保证
sysbench版本、MySQL 版本、innodb_flush_method一致，否则 benchmark 失效
最常被忽略的一点：压测前没关 query cache（MySQL 5.7+ 已废弃，但老版本仍默认开），它会让重复查询秒返回，完全扭曲真实执行耗时。
