如何进行mysql压力测试_并发测试思路

来源：这里教程网时间：2026-02-28 20:35:34 作者：

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 不再上升，但