MySQL压力测试核心是验证高负载下稳定性、响应速度和资源消耗，需模拟真实读写比、连接行为与事务复杂度，并分层使用sysbench、JMeter等工具，结合多维监控定位瓶颈。
MySQL压力测试和并发测试的核心目标是验证数据库在高负载下的稳定性、响应速度和资源消耗情况，而不是单纯追求QPS峰值。关键在于模拟真实业务场景中的读写比例、连接行为、事务复杂度和数据分布。
明确测试目标和基准指标
开始前先定义清楚要测什么：是单表随机读？混合事务（如订单创建+库存扣减）？还是长连接下的持续写入？对应关注的指标也不同：
- 响应时间（P95/P99）：比平均值更有意义，尤其对交互类业务
- 吞吐量（QPS/TPS）：需注明读写占比（如 70% 读 + 30% 写）
- 错误率：超时、死锁、连接拒绝等是否在可接受范围内
- 服务端资源水位：CPU、内存、InnoDB Buffer Pool 命中率、IOPS、慢查询增长趋势
选择合适工具并贴近真实链路
不推荐只用 sysbench 简单跑个 oltp_read_write 就下结论。应分层验证：
- 协议层压测：用 sysbench 或 tpcc-mysql，控制连接数、线程数、事务大小，重点观察 MySQL 自身表现
- 应用层压测：用 JMeter/Go-wrk 模拟实际 API 调用，包含连接池行为（如 HikariCP 的 maxPoolSize、connectionTimeout）、重试逻辑、参数化查询
- 混合负载注入：在主压测流量外，叠加定时任务（如每分钟一次大表统计）、后台 binlog 解析或从库同步压力
注意：sysbench 默认使用长连接，若业务是短连接（如 PHP-FPM 场景），需加 --time=60 --threads=100 --rate=100 控制发压节奏，并监控 `Threads_created` 是否飙升。
设计有代表性的测试数据与SQL
避免“理想数据”带来的误判。真实场景中常有热点数据、非均匀分布、二级索引失效等问题：
- 用
sysbench --range-size=1000控制主键范围，模拟局部热点 - 添加非主键条件查询（如
WHERE status=1 AND create_time > '2024-01-01'），检验执行计划是否走索引 - 插入阶段开启
--tables=16 --table-size=1000000，确保 Buffer Pool 无法全量缓存，触发磁盘IO竞争 - 对高频更新字段（如余额、状态）单独建覆盖索引，再压测看锁竞争是否加剧
监控必须贯穿全程且分维度对比
光看 QPS 上不去就调 innodb_buffer_pool_size 是无效的。要建立“请求→MySQL内核→OS→存储”的关联视图：
-
MySQL 层：实时查
SHOW ENGINE INNODB STATUS中的 semaphore waits、lock wait 数量；用 performance_schema 分析 mutex 等待、file io 统计 -
系统层：用
pt-pmp抓堆栈，确认 CPU 高是解析 SQL 还是刷脏页；用iostat -x 1看 await 和 %util 是否异常 - 对比基线：同一脚本在 100 并发 vs 500 并发下，QPS 是否线性增长？P99 是否陡增？若有拐点，定位是锁、IO 还是网络包丢弃
一个典型线索：QPS 卡在 2000 不再上升，但 show processlist 显示大量 updating 状态，同时 Innodb_row_lock_waits 持续增加 → 很可能是某张小表被高频更新导致行锁争用。
不复杂但容易忽略
压测不是一次性动作。每次调整参数或SQL后，至少跑三轮（冷启动、稳态、回收期），取第二轮中间5分钟数据为准；记录所有变量：MySQL 版本、binlog_format、隔离级别、tmp_table_size 设置、甚至磁盘调度算法。否则结果不可复现，优化无从谈起。
