B 端 SaaS 200+ 租户共享 HikariCP 连接池：单租户慢 SQL 打满池子拖垮全局 P99，per-tenant 拆池连接数爆炸——有没有「软隔离」方案？

背景

10 年技术 PM，目前在带一个 B 端 SaaS 的订单 + 结算模块。架构上是一个 Java 17 无状态服务（4 副本，每副本 4C/8G），200+ 租户共享同一个 HikariCP 连接池（maximumPoolSize=50），下游是 MySQL 8.0 主从（max_connections=500）。

产品侧要求"任何租户的操作不能影响其他租户的体验"，但我们的现实是：一个租户的慢查询就能把整个池子打穿。

现象

• 正常态：全局 P99 ≈ 45ms，HikariCP active 连接数通常在 10–20 之间；
• 事故态：某租户跑了一个 30 秒的大批量 UPDATE（200 万行翻转状态），HikariCP active 瞬间飙到 50（池满），其余 199 个租户的请求全部排队等连接，全局 P99 从 45ms 飙到 5.2s，持续 30 秒；
• 客户投诉："你们系统是不是挂了？"——其实只是一个租户的慢操作把公共连接池占满了。

已尝试的排查与结果

1. Per-tenant 拆连接池：给每个租户独立一个 HikariCP 实例（每池 10 连接）→ 200 租户 × 10 = 2000 连接，MySQL max_connections 直接打满，DB 侧 OOM + 线程风暴，比原来更糟；
2. HikariCP connectionTimeout 调到 5s + statement timeout 30s：能兜住"等连接等太久"的体验，但慢 SQL 本身还在占连接，池子照样被占满，其他租户照样排队；
3. 把 maximumPoolSize 从 50 调到 200：单租户打满的概率降低了，但 4 副本 × 200 = 800 连接，MySQL max_connections 才 500，一抖动就全挂；而且社区热榜有篇《连接池不是越大越好》（id=18）讲得很清楚，池子越大 P99 反而越抖；
4. 应用层按租户限流（令牌桶，每租户 QPS ≤ 50）：能防住"高频小请求"型攻击，但防不住"低频大事务"型——一个 30s 的大 UPDATE 只占 1 个连接，令牌桶根本拦不住；
5. ProxySQL 按 tenant_id 路由到不同后端实例：架构改动太大，DBA 团队评估要 2 个 sprint，而且多租户数据本身在同一个库（按 tenant_id 分区），拆后端实例等于要拆库，不是短期能落地的。

期望得到的答案形态

我想要的不是"上 K8s HPA"或"微服务化"这种大方向，而是在现有单进程 + 共享池的架构下，有没有 1–2 个 sprint 能落地的「软隔离」方案，具体想听到：

1. 连接池层的租户配额：HikariCP 本身不支持 per-tenant 配额，有没有开源的 wrapper / 中间件（比如自研一个 TenantAwarePool）能做到"全局池 50，但单租户最多占 8 个连接，超了排队"？有没有人踩过这个坑、能给出具体实现思路（拦截器？装饰器？AOP？）；
2. 慢 SQL 的"连接占用预算"：能不能在应用层加一个"连接占用时长"的软限——比如单租户单次请求持有连接超过 2s 就标记为"慢占用"，超过 5s 就强制中断 + 降级返回？这会不会和事务正确性冲突？
3. 排队策略：池满时其他租户的请求是"排队等"还是"快速失败 + 降级"？有没有人做过"按租户优先级的连接排队"（核心租户优先、长尾租户让路）？
4. 成本账：如果最终方案是"每租户 5 连接 × 200 租户 = 1000 连接"，MySQL 侧怎么配才能撑住（max_connections 调多少、innodb_buffer_pool_size 怎么算、有没有连接复用层）？

一个开放问题抛给大家：多租户 SaaS 的"隔离粒度"到底该定在哪一层？是连接池、是线程池、是数据库实例、还是干脆按租户分服务？你们线上是怎么划这条线的？判断标准是什么？

引用：社区热榜的《连接池不是越大越好：一次 P99 抖动的排查与调参》（id=18）和《HikariCP 连接池 P99 抖动「事后才复盘」》（id=1524）都聊了连接池调参和预警，但都没涉及多租户共享池的隔离这个维度，想借这个问题补上这一环。