MySQL 连接数与 QPS 齐涨、P99 却飙 15 倍：InnoDB 锁排队下「加连接 = 加等待」的复盘

一、现象与背景：连接数翻倍，接口反而更慢

先给结论：当瓶颈在 InnoDB 行锁排队时，把连接数加上去，QPS 会微涨、P99 会暴涨，因为新连接只是多排队的人，不是多干活的人。

具体场景：一个库存扣减服务，MySQL 8.0.32（16C64G，InnoDB，单表 t_stock 约 8200 万行），上游 24 个 JVM 实例，每个实例 HikariCP maximumPoolSize=50，合计 1200 条连接。某次大促压测中：

• 基线（池 30/实例，合计 720）：QPS 4200，P50 6.8ms，P99 14ms
• 调大后（池 50/实例，合计 1200）：QPS 4310（+2.6%），P50 7.1ms，P99 涨到 210ms（约 15 倍）
• Threads_connected 从 720 → 1200，但 Threads_running 始终在 30~48 之间

监控曲线非常典型：连接数阶梯上升，P99 跟着阶梯式恶化，QPS 几乎是一条平线。

二、原理：为什么加连接会放大尾延迟

关键在于区分三个指标：

1. Threads_connected：当前已建立的连接数，含大量空闲连接，不代表并发度；
2. Threads_running：正在执行 SQL 的线程数，才接近真实并发；
3. InnoDB 锁等待：真正决定 P99 的地方。

我们的慢 SQL 是热点行更新：UPDATE t_stock SET qty = qty - ? WHERE sku_id = ?，压测脚本里 12% 的流量集中在约 400 个热门 SKU 上。InnoDB 对同一行的并发更新会挂到该记录的 lock wait queue 上，等待是串行的：第 N 个请求的等待时间 ≈ 前面 N-1 个请求的执行时间之和。

这里有个容易被忽略的放大机制——排队论里的 Little 定律：L = λ × W（平均排队长度 = 到达率 × 平均等待时间）。当服务率（能真正推进更新的并发度，受锁与 CPU 限制）固定时，你往系统里塞更多并发请求，不会提高吞吐，只会让平均等待时间线性拉长，而 P99 是分布的长尾，拉长比 P50 更剧烈。

另外两层开销常被低估：

• 线程上下文切换：1200 条连接里有 60 个在真正跑 SQL，其余 1100+ 个在 epoll_wait / 锁等待上睡醒，调度器要频繁切换，/proc/pressure/cpu 的 some 值从 2.1% 涨到 9.4%；
• 锁等待放大回滚链：等待方持有的 gap lock / next-key lock 会让范围扫描类查询也变慢，连带 SELECT ... FOR UPDATE 的读路径 P99 从 9ms 涨到 60ms。

三、具体做法：限并发、降连接、把排队挪到客户端

1. 用 information_schema 确认瓶颈是锁而不是 IO

SELECT COUNT_STAR AS waiting
FROM performance_schema.events_waits_summary_global_by_event_name
WHERE EVENT_NAME LIKE 'wait/lock/table/innodb/table_lock%'
   OR EVENT_NAME LIKE 'wait/lock/table/innodb/row_lock%';

-- 每 5s 采一次，看 wait time 是否随连接数上涨
SHOW GLOBAL STATUS LIKE 'Innodb_row_lock_waits';

我们的数据：Innodb_row_lock_waits 在 1 小时内从 1.2 万涨到 38 万，而 Innodb_buffer_pool_reads（物理读）几乎不动——明确是锁排队，不是磁盘。

2. 客户端限并发，而不是加连接

# HikariCP 每实例
maximumPoolSize=24          # 从 50 降回，按 CPU/锁并发上限反推
connectionTimeout=2000      # ms，快速失败而不是排队 30s
maxLifetime=180000

同时在上游网关加信号量限流：全局 64 个并发扣减令牌（≈ 16C × 4），超出的请求在业务层排队或降级，而不是全部压到 MySQL 上排队。

3. 把热点行拆散，缩短单次锁持有时间

• 单行 UPDATE 拆成 分桶库存：sku_id 拆成 8 个 bucket，qty = SUM(bucket)，每次只更新 1 个 bucket，锁冲突概率降到 1/8；
• 事务内先校验后更新，把 SELECT 移出事务（我们的事务里原来有个 12ms 的远程校验 RPC，直接砍掉，锁持有时间从 19ms → 6ms）；
• 对超高热 SKU 走本地内存扣减 + 异步落库（批量 500 条 / 500ms 合并写）。

4. 观测面板必看的 5 个指标

| 指标 | 来源 | 判断 | |---|---|---| | Threads_running | status | 真实并发上限 | | Innodb_row_lock_time_avg | status | 单次锁等待均值 | | Innodb_row_lock_waits | status | 累计等待次数 | | cpu pressure some | PSI | 调度压力 | | P99 vs P50 比值 | 应用侧 | 排队是否恶化 |

四、踩过的坑与反直觉之处

1. 看 Threads_connected 判断负载是错的：它 1200 的时候，真正在跑的只有 40 个。我们第一反应是「连接没打满，还能加」，加了之后 P99 直接爆炸。正确姿势是看 Threads_running 和锁等待。
2. QPS 没掉 ≠ 没劣化：吞吐在锁瓶颈下接近饱和，加并发几乎不涨 QPS，但 P99 会先崩。压测只看平均 QPS 会漏掉最致命的问题。
3. innodb_thread_concurrency 不是银弹：我们试过设成 32，效果有限——它限的是进入 InnoDB 的线程数，但锁排队发生在记录级别，限了线程数，队列还是在。真正的解法是减少锁持有时间 + 拆分热点。
4. 降连接数后短期 QPS 掉了 4%：业务方一度要回滚。但 P99 从 210ms 回到 16ms，配合分桶后 QPS 反而做到 4800。先牺牲 4% 的均值换 13 倍的 P99，是划算的。
5. max_poll 式的心跳参数（Kafka 那套）在这里不适用：MySQL 连接空闲不会被踢，wait_timeout 默认 28800s，僵尸连接会长期占着 Threads_connected 的坑位，但完全不影响锁——又一次证明 connected 是误导性指标。

五、结论与可复用清单

结论：InnoDB 行锁是串行资源，加连接只是加排队者；P99 恶化的第一嫌疑是锁持有时间 × 并发度，而不是连接数本身。

可复用清单（按优先级）：

1. 压测 P99 恶化时，先采 Threads_running + Innodb_row_lock_waits + Innodb_buffer_pool_reads 三件套，用数据区分「锁 / IO / CPU」三类瓶颈，再动手；
2. 客户端连接池大小以「真实并发上限 + 少量冗余」为准，connectionTimeout 调到秒级快速失败，别把排队堆在服务端；
3. 热点行更新三板斧：拆桶、缩短事务、异步合并，锁持有时间减半 ≈ P99 减半；
4. 压测指标必须同时看 P50 / P99 / QPS 三条曲线，QPS 平 + P99 涨 = 排队瓶颈的典型信号；
5. 上信号量 / 令牌桶把并发限制在应用层，让 MySQL 只看到「它扛得住的并发」；
6. 变更窗口内做 A/B：连接数 30 vs 50 各压 10 分钟，用 P99 分布而不是均值做决策。

参考：文中 MySQL 8.0.32 实测数据来自我们库存服务 2025-Q1 压测环境；排队论部分参考 Little 定律（L = λW）与 InnoDB lock wait queue 文档（docs.oracle.com/cd/E17782_01 及 8.0 手册 Chapter 15）。