评估mysql并发能力需模拟真实业务多连接压力，关注响应时间、qps/tps、错误率及资源消耗，分阶段加压识别瓶颈，压测后分析慢日志、执行计划并确保环境同构。
评估 MySQL 并发能力，核心是模拟真实业务场景下的多连接、多请求压力，观察系统在不同并发量下的响应时间、吞吐量、错误率及资源消耗。不能只看单条 SQL 的执行速度，而要关注连接池、锁竞争、缓冲区、磁盘 I/O 和 CPU 等整体协同表现。
明确压测目标和关键指标
压测前先定义清楚要验证什么：是支撑 1000 QPS 的读请求？还是扛住 200 个并发写入不丢数据？常见必须监控的指标包括：
- QPS（每秒查询数）和 TPS（每秒事务数）：反映吞吐能力
- 平均响应时间 & 95/99 分位响应时间：比平均值更能暴露长尾问题
- 错误率（超时、连接拒绝、Deadlock、Lock wait timeout）：直接体现稳定性瓶颈
- MySQL 内部状态：Threads_connected、Threads_running、Innodb_row_lock_waits、Innodb_buffer_pool_wait_free 等
- 服务器资源：CPU 使用率（尤其用户态）、内存使用、磁盘 I/O 等待（iowait）、网络带宽
选择合适工具并构造真实负载
工具只是手段，关键在负载是否贴近生产：
-
sysbench：最常用，支持 OLTP 只读/读写混合、点查、范围扫描等模式；建议用
--oltp-tables-count=8 --oltp-table-size=1000000避免单表过小导致缓存全命中，失真 - mysqlslap：轻量，适合快速验证简单语句并发，但不支持事务和复杂逻辑
- 自研脚本（Python/Go）：当需要模拟真实业务链路（如“查用户→扣库存→写订单”跨表事务），或带随机参数、失败重试、JWT 鉴权等逻辑时更可靠
- 注意：所有压测客户端应分散部署，避免单机网络/端口耗尽或自身成为瓶颈
分阶段递增并发，识别拐点
不要一上来就冲高并发。推荐阶梯式加压（例如：32 → 64 → 128 → 256 → 512），每个阶段持续 3–5 分钟，并记录完整指标：
- 观察 QPS 是否线性增长——若增长变缓甚至下降，说明已出现瓶颈
- 响应时间突增 + Threads_running 持续高位 → 可能是锁争用或 CPU 饱和
- 大量 Lock wait timeout 或 Deadlock → 检查事务粒度、索引覆盖、隔离级别（如是否误用 SERIALIZABLE）
- InnoDB buffer pool 命中率跌破 95% → 考虑加大 innodb_buffer_pool_size 或优化查询减少扫描
压测后必做的三件事
压测结束不是终点，而是调优起点：
- 分析慢日志（slow_query_log）：开启 long_query_time=0.1，配合 pt-query-digest 统计高频慢 SQL
- 检查执行计划（EXPLAIN）：确认压测 SQL 是否走了预期索引，有无 filesort / temporary 表
- 对比配置合理性：如 max_connections 是否足够、innodb_log_file_size 是否适配写入量、query_cache 已废弃勿启用
不复杂但容易忽略：压测环境必须与生产同构（相同版本、相同硬件规格、相同参数模板），且压测期间关闭监控告警干扰，避免误触发自动扩缩容或限流策略干扰结果。
