MySQL性能压测核心是“有目标、可复现、能对比”，需明确目标与指标、构造真实数据和SQL、选用合适工具并控制变量、全程监控MySQL内外部状态。
MySQL 性能压测不是单纯跑个工具看 QPS，关键在于模拟真实业务场景、定位瓶颈并验证优化效果。核心是“有目标、可复现、能对比”。
明确压测目标和指标
压测前必须定义清楚：是要验证新硬件承载能力？评估 SQL 优化效果？还是测试主从同步延迟？不同目标决定不同的关注指标：
- 吞吐类：QPS（每秒查询数）、TPS（每秒事务数）
- 响应类：平均响应时间、P95/P99 延迟、超时率
- 资源类：MySQL CPU 使用率、InnoDB Buffer Pool 命中率、磁盘 IOPS 和 IO 等待、连接数占用
- 稳定性类：长时间运行是否出现连接堆积、慢查询激增、OOM 或主从延迟跳涨
构造贴近生产的数据和 SQL
用空表或百万级随机数据压测意义有限。真实瓶颈常出现在数据分布、索引选择性、锁竞争等环节：
- 数据量至少达到生产预估的 1:1，比如线上预计 2TB，压测库也应接近该规模
- 主键和二级索引字段需模拟真实倾斜度（如用户 ID 分布不均、时间字段高度递增）
- SQL 类型按业务比例混合：60% 简单点查（带索引）、20% 范围查询（如时间范围分页）、15% 写入（INSERT/UPDATE）、5% 复杂 JOIN 或子查询
- 避免全表扫描语句主导压测——它掩盖了索引优化的真实收益
选用合适工具并控制变量
工具只是手段，关键是让每次压测条件可控、结果可比：
-
sysbench：适合基础组件级验证（CPU/IO/内存/网络），推荐使用 1.0+ 版本，搭配
--db-driver=mysql和真实 SQL 脚本（非内置 oltp_* 模板） - mysqlslap：轻量快速验证单条 SQL 并发表现，适合开发自测，但不支持复杂事务流
- 自研脚本（Python/Go）：最灵活，可精确控制请求节奏、参数变化、失败重试逻辑，适合模拟微服务调用链
- 每次只调整一个变量：比如固定并发线程数，只改 buffer_pool_size；或固定配置，只换 SQL 优化版本
监控必须贯穿全程
压测时只看客户端输出是危险的——MySQL 内部可能已严重抖动：
- 开启
performance_schema+sys schema，实时查wait/io/file/innodb/innodb_data_file_read等等待事件 - 用
SHOW ENGINE INNODB STATUS\G观察锁等待、事务状态、buffer pool 使用碎片 - 采集
information_schema.INNODB_METRICS中的lock_row_lock_time_avg、buffer_pool_hit_rate - 配合系统层监控：
iostat -x 1看 await、%util；vmstat 1看 si/so、cs；pidstat -u -t -p $(pgrep mysqld) 1看线程级 CPU
不复杂但容易忽略的是：压测前后做一次 FLUSH STATUS，再用 SHOW STATUS LIKE 'Com_%' 对比增量，能快速识别执行计划变更或隐式类型转换问题。
