用sysbench压测MySQL需分四步：准备阶段环境对齐与数据预热；执行阶段分层递进压测（只读→读写→更新）；监控阶段同步采集MySQL内核、OS、网络指标；归因阶段依现象反推瓶颈并单变量验证优化效果。
用 sysbench 对 MySQL 做压测，核心是模拟真实负载、定位瓶颈、验证优化效果。不是跑个命令就完事，关键在参数设计、指标观察和结果归因。
准备阶段：环境对齐 + 数据预热
压测前必须确保测试环境与生产尽可能一致：MySQL 版本、配置（尤其是 innodb_buffer_pool_size、max_connections）、磁盘类型（SSD/NVMe）、网络延迟。避免在开发机或容器里直接跑——资源隔离不足会导致结果失真。
数据量要够大：单表至少 100 万行以上，否则缓存命中率虚高，压不出 IO 或锁竞争问题。用 sysbench 自带的 oltp_point_select 脚本初始化时，加 --tables=16 --table-size=1000000；完成后执行 FLUSH TABLES; 清空缓冲，再做 warmup（跑 30 秒预热）。
压测执行：分层递进 + 多维度参数组合
别一上来就用 512 线程狂刷。按阶梯推进：
- 先跑 oltp_read_only（只读），观察 QPS 和响应时间拐点，判断查询层吞吐上限
- 再跑 oltp_read_write（读写混合），重点看 transactions per second (tps) 和 queries per second (qps) 是否同步下降——若 tps 掉但 qps 持平，大概率是写锁或 binlog 刷盘拖慢
- 最后用 oltp_update_non_index 单独压更新路径，验证索引设计是否合理（比如 where 条件无索引时，响应时间会指数级上升）
每个阶段固定运行时长（如 120 秒），用 --time=120 --threads=32,64,128,256 批量跑，生成可对比的吞吐曲线。
监控重点：不止看 QPS，更要盯住数据库内核指标
光看 sysbench 输出的 tps/qps 是不够的。必须同步采集：
- MySQL 内部状态：每秒 Threads_running（持续 > 20 需警惕）、Innodb_row_lock_waits（锁等待次数突增说明事务冲突严重）、Slow_queries（配合 long_query_time=1 捕获隐式慢 SQL）
- OS 层资源：iostat -x 1 看 %util（> 80% 表示磁盘饱和）、await（> 20ms 说明 IO 延迟高）；vmstat 看 si/so（有换页说明内存不足）
- 网络与连接：netstat -s | grep "retransmitted"（重传率 > 1% 可能存在丢包或网卡打满）
建议用 pt-stalk 或自建脚本每 5 秒快照一次，压测后对齐时间轴分析异常点。
结果归因：从现象反推具体瓶颈
常见现象与根因对应关系：
- QPS 上不去，CPU 使用率低 → 查 show processlist 是否大量线程卡在 Waiting for table metadata lock 或 Waiting for global read lock，检查是否有长事务或 DDL 未完成
- 平均响应时间陡升，95% 延迟远高于均值 → 很可能是个别慢查询拖累整体，抓 slow log 或用 performance_schema.events_statements_summary_by_digest 找执行时间最长的 digest
- TPS 随线程增加反而下降 → 典型锁竞争，开 innodb_status 看 SEMAPHORES 区域的 spin waits 和 os waits 比例，过高说明自旋+系统等待严重
每次调优后，只改一个变量（比如只调大 innodb_log_file_size），重新压测对比，避免多变量干扰结论。
