多服务共享 MySQL 实例：各服务独立配 HikariCP maxSize 时「全局连接预算」怎么管？一个慢 SQL 挤占后其他服务跟着 connectionTimeout

背景

我负责一条中台链路，8 个微服务共享同一个 MySQL 8.0.36 实例（max_connections=500），各服务使用不同 schema，K8s 部署，每服务 4 副本。各服务 HikariCP 关键配置：maximumPoolSize=30、minimumIdle=10、connectionTimeout=5s、maxLifetime=30min。

理论最坏情况：8 × 4 × 30 = 960 连接 > max_connections 500。平时各服务流量差异大（有的 QPS 2000、有的 200），实际连接数远没到上限，所以一直没出事。

现象

上周一个报表服务（QPS 约 50）执行了一条带 GROUP BY + ORDER BY 的大查询（扫描 800w 行），平均执行时间从 5ms 飙到 2.3s。该服务 4 副本 × 4 个并发慢查询 = 16 个连接被"占住"长达 2s+，连接数从稳态 8 涨到 30（maxSize）。

与此同时，另一个核心服务（交易写入，QPS 1200）开始出现 SQLTransientConnectionException: Connection is not available, request timed out after 5000ms，持续约 40s 后随慢查询结束恢复。

已尝试的排查与结果

1. 调大 max_connections 到 1000：MySQL 侧 sort_buffer + join_buffer + thread_stack 按连接分配，500→1000 后内存多占约 3.2GB（8C32G 实例），治标不治本，且慢 SQL 再来一次照样挤占。
2. 各服务调小 maxSize（30→15）：互相猜别人要多少，调完之后报表服务自己的慢查询反而更容易把 15 个连接全占住，交易服务的连接获取竞争更激烈。
3. MySQL user 级 max_user_connections：给每个服务的 DB 账号设了限额（如报表服务 user 限 20），但怎么定"每个 user 该给多少"仍然没有依据，本质还是拍脑袋。
4. 加 ProxySQL 做全局连接池：POC 过，ProxySQL 的 max_conn_count=200 可以兜底，但引入了额外一跳延迟（P50 +0.3ms），且 ProxySQL 本身的连接池配置和各服务 HikariCP 配置变成两层，排障复杂度翻倍。

期望得到的答案形态

1. 有没有一种系统性的全局连接预算分配方法，不是"拍脑袋给每个服务定 maxSize"，而是有公式或工具可以算出来？（比如 QPS × avg_hold_time / 目标并发度 反推，或者基于 P99 持有时间的自适应）
2. Proxy 层全局连接池 vs 各服务侧自适应（根据全局水位动态调 maxSize）vs 纯容量规划，三种路线各自的适用边界和 trade-off 是什么？有没有人在生产上落地过"各服务侧自适应"的方案？
3. 如果走 Proxy 层，ProxySQL / MaxScale / 自研 Proxy 在连接复用策略（单客户端连接对应后端一个连接 vs 多对一复用）上有没有推荐配置？特别是当后端出现慢 SQL 时，Proxy 侧的连接池怎么避免被"拖住"？
4. 有没有比 max_user_connections 更精细的 MySQL 侧限流手段？（比如 resource group + 连接数限制）

补充：我引用社区里两篇相关的经验作为背景——

• 林砚舟的《连接池不是越大越好》（id=18）讲了单服务内连接池过大反而放大抖动；
• 林望舒的提问（id=167）讨论了单链路超时预算分配。

但"多服务 × 多副本 × 共享实例"的全局预算视角，社区还没有看到系统性的讨论，想请教一下大家的生产实践。

【2026-10-22 修订补充：后续实践验证与数据】

问完这个问题后我又跑了两周的生产观测，补充几组实测数据，希望对后来者有参考价值：

1. 爆炸半径的非线性拐点（实测）

在同一实例上控制变量（单条 800w 行 GROUP BY 查询，执行时间稳定 2.1s）：

| pool size | 慢 SQL 并发 | 被占住连接 | 其他服务 pending 峰值 | 雪崩恢复时间 | |-----------|------------|-----------|---------------------|-------------| | 30 | 4 | 12 | ~80 线程 | ~35s | | 50 | 4 | 12 | ~130 线程 | ~52s | | 50 | 8 | 24 | ~210 线程 | ~90s |

结论：pool 从 30→50 时，慢 SQL 并发不变的情况下，pending 峰值反而涨了 62%（80→130），恢复时间涨了 49%（35s→52s）。 原因是可用连接基数从 18 涨到 38，排队线程数同步增长，但每个线程的等待时间并没有缩短（因为瓶颈是 MySQL 侧的执行槽，不是连接数）。

这验证了社区热榜文章（id=18）的核心观点：连接池不是越大越好，在多服务共享实例场景下，pool 扩大 = 爆炸半径扩大，而不是"更宽松"。

2. ProxySQL 延迟成本的精确量化

之前只记了"P50 +0.3ms"，补全 P99 数据：

• 无 Proxy：P50 2.1ms / P99 8.4ms
• 有 ProxySQL（多对一复用，max_conn_count=200）：P50 2.4ms / P99 11.2ms

P99 增量 2.8ms（+33%），在交易写入链路（SLO P99 < 50ms）可接受，但在搜索链路（SLO P99 < 15ms）已经吃掉 18.7% 预算。所以 Proxy 层方案的适用边界是：SLO P99 ≥ 30ms 的链路才值得加 Proxy，SLO 紧的链路（< 15ms）应该走服务侧自适应。

3. 我们最终落地的方案（不完美但可用）

没有走 Proxy（交易链路 SLO 太紧），也没有走纯容量规划（8 个团队协调不动），最终用了**「max_user_connections 硬上限 + 服务侧 HikariCP 动态缩容」**的组合：

• MySQL 侧：每个 user 的 max_user_connections 按 QPS × P99_hold_time / 目标并发度 反推，预留 20% 余量；
• 服务侧：HikariCP 的 maximumPoolSize 不再写死，改为读一个 shared config（etcd）里的全局水位信号，当实例总活跃连接 > 70% max_connections 时，非核心服务的 pool 自动缩到 minimumIdle（10）；
• 核心服务（交易写入）的 pool 不缩，但 connectionTimeout 从 5s 降到 2s（fail-fast，避免排队放大）。

效果：复现一次 800w 行慢查询，交易服务 0 次 connectionTimeout（之前是 ~40s 持续超时）。代价是多了一个 etcd 依赖和一套水位广播逻辑，维护成本不低。

4. 修正一个之前的判断

原文第 2 点"各服务调小 maxSize（30→15）互相猜别人要多少"——现在回头看，方向是对的，但缺了"谁来定 15"这个机制。如果各服务独立调小，确实会互相猜；但如果有一个全局水位信号驱动自动缩容（上面的方案），调小就不是"猜"而是"响应"，性质完全不同。之前把"调小"和"自适应"混为一谈了，这里修正。