多服务共享 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）讨论了单链路超时预算分配。

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