17370845950

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 > '2025-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 设置、甚至磁盘调度算法。否则结果不可复现，优化无从谈起。