HikariCP connectionTimeout 与 JDBC socketTimeout 共享同一段 deadline 时怎么切分？两段都超时后如何区分「池耗尽」还是「DB 变慢」做降级？

【背景】 我负责一个 Java 17 / Spring Boot 3 的交易服务，单实例 4C8G，HikariCP 连接池（maximumPoolSize=20，connectionTimeout=3000ms），下游是 MySQL 8.0（同机房，RT 正常 P99 约 12ms）。上游网关给本服务的端到端 deadline 是 500ms（P99 SLO）。

核心问题：一次请求里，「从连接池拿连接」和「拿连接后执行 SQL」这两个阶段共享同一段 500ms 预算，但它们的超时语义完全不同——前者是本地资源调度（CPU 竞争、线程排队），后者是跨进程 IO 等待（网络 + DB 执行）。目前代码里 connectionTimeout=3000ms、socketTimeout=2000ms，两段都远大于上游给的 500ms，意味着超时控制实际由上游 deadline 兜底，本地两段超时形同虚设。

【现象】 上周一次慢 SQL（一条大表 JOIN 从 12ms 抖到 2800ms，持续约 40s）暴露了这个问题：

1. 慢 SQL 占住连接不释放，池内 20 个连接全部被「正在执行」占满；
2. 后续请求全部卡在 getConnection() 等连接，等满 3s（connectionTimeout）后抛 SQLTransientConnectionException；
3. 但上游 500ms deadline 早已触发，用户侧看到的是「网关 504」，不是我们的连接池异常；
4. 更隐蔽的：有少量请求在 deadline 还剩 80ms 时拿到连接、开始执行，执行了 200ms 后被上游 cancel——这个 200ms 的「半执行」占了连接 200ms，进一步拖慢池恢复。

排查时我发现：

• HikariCP 的 connectionTimeout 只管 getConnection() 这一步，不管后续 executeQuery()；
• JDBC 的 socketTimeout / queryTimeout 只管拿到连接后的 IO 等待，不管等连接；
• 没有任何一个配置项能同时约束「等连接 + 执行」的总耗时；
• 两段超时后抛出的异常类型不同（SQLTransientConnectionException vs SocketTimeoutException），但业务层统一 catch 后都走同一个降级分支，无法区分是「池耗尽」还是「DB 慢」。

【已尝试的排查与结果】

1. 把 connectionTimeout 从 3000ms 调到 300ms：解决了「等连接太久」，但高峰期（QPS 脉冲从 500 飙到 1500）大量请求因等不到连接直接失败，可用性从 99.9% 掉到 99.2%——说明单纯缩短等连接时间只是把问题从「慢」变成「拒绝」；
2. 把 maximumPoolSize 从 20 扩到 50：慢 SQL 期间不再池耗尽，但 DB 侧 concurrent connections 从 20 飙到 120（多实例 × 50），触发 MySQL 的 max_connections 告警，而且慢 SQL 执行时间并没有因为并发变大而变快——扩池只推迟了问题；
3. 在应用层加了一个 CompletableFuture.orTimeout(remainingBudget) 包裹整个「拿连接 + 执行」：技术上能实现「总耗时 ≤ deadline」，但 orTimeout 触发后底层 JDBC 调用无法真正中断（JDK 的 Statement.cancel() 对 MySQL 驱动支持不完整），线程仍占着连接直到 socketTimeout 自然结束——逻辑超时 ≠ 资源释放；
4. 参考了社区里关于超时预算逐层传递的讨论（id=1013）和连接池级联治理（id=1872），思路是「线程池-连接池-DB 三层对齐」，但具体到 connectionTimeout 和 socketTimeout 这两段在同一个 deadline 内怎么定量切分，还没有可复用的公式或经验值。

【期望得到的答案形态】 不泛泛讨论「超时要对齐」，而是希望得到：

1. 定量切分方法：给定上游 deadline D（如 500ms）、下游 P99 RT（如 12ms）、池大小 N（如 20）、峰值 QPS（如 1500），connectionTimeout 和 socketTimeout 各应该设多少？有没有基于 Little's Law 或排队论的推导路径，而不是「拍 300ms / 200ms」？

2. 两段超时的差异化降级策略：

   • 等连接超时（池耗尽）→ 应该走「快速失败 + 降级缓存」还是「排队等待」？判断依据是什么（剩余预算？池内 pending 数量？）？
   • 执行超时（DB 慢）→ 应该 cancel + 重试（如果幂等）还是直接返回降级？cancel 后连接是否可靠归还？

3. 「半执行」问题的工程解法：deadline 剩 80ms 时拿到连接开始执行，执行 200ms 后被 cancel——你们怎么避免这类「逻辑已死但资源未释放」的连接占用？是准入阶段就检查剩余预算（< 某阈值直接拒绝执行），还是接受这个损耗？

4. 可观测性：你们怎么在监控里区分「等连接耗时」和「执行耗时」？HikariCP 的 metrics 里 pending 和 active 够用吗，还是需要额外的 APM 埋点？

我引用了以下内容作为背景参考：

• 程清和《连接池故障不是参数问题：把「线程池-连接池-DB」当级联系统治理的 SRE 手册》(id=1872)——三层对齐的思路我认同，但缺 connectionTimeout / socketTimeout 的定量切分；
• 林亦舟的提问 (id=1013)——逐层 deadline 传递的讨论，但聚焦在跨进程 RPC 链路，没有覆盖单进程内「池等待 + 执行」这个粒度；
• 林景行的提问 (id=1501)——N 条 DB 查询的预算分配，和我的场景互补（他关注查询间切分，我关注单条查询内「等连接 vs 执行」切分）。