HikariCP 连接 active 但实际空闲：请求拿到连接后先调下游 HTTP 再执行 SQL，这种「连接过度持有」怎么检测、怎么改？

背景

我负责一个订单结算服务（Spring Boot 3.2 + JDK 17 + HikariCP 5.1，K8s 部署，4 副本，单副本 8C16G）。一个典型请求的处理流程是：

1. 从 HikariCP 拿到 MySQL 连接（用于后续写订单状态）
2. 调用下游「账务服务」HTTP 接口（P50=35ms，P99=800ms，超时设 1.5s）
3. 拿到账务返回后，用步骤 1 拿到的那个连接执行 UPDATE orders SET status=?
4. 归还连接

看起来只是「先查后写」的常规流程，但步骤 2 的下游 HTTP 调用期间，那个 MySQL 连接被白白占着——既没在读也没在写，纯粹是「持有中」。HikariCP 的 activeConnections 指标会把它算进去，但 threadsAwaitingConnection 为 0，看起来一切正常。

现象

• 稳态 QPS 约 600，maximumPoolSize=30，平时 active 数在 8~15，看起来余量充足。
• 但下游账务服务偶尔批次处理（P99 飙到 1.2s+），此时 active 连接数瞬间冲到 28~30，池子接近打满。
• 紧接着另一个并发请求要拿连接，connectionTimeout 默认 30s 还没到就开始排队，P99 从 50ms 飙到 1.5s+。
• 关键矛盾：MySQL 侧 SHOW PROCESSLIST 里那些连接全是 Sleep 状态，它们并没有在干活，只是在「等上游把 HTTP 调用做完」。

已尝试的排查与结果

1. 调大 maximumPoolSize 到 60：治标不治本，下游再抖一次还是打满，而且 MySQL max_connections 是和其他服务共享的（参考 id=1358 的讨论），全局预算更紧张。
2. 把 connectionTimeout 从 30s 缩到 2s：快速失败是快了，但业务侧报错率上升，客诉变多。
3. 加 HikariCP 的 leakDetectionThreshold=5000：它只在连接归还后检测「持有超 5s 未归还」，但我的场景里连接最终都归还了，只是持有时间过长，这个检测不会触发。
4. AOP 切面统计每个连接的持有时间：确认了 80% 的持有时间消耗在下游 HTTP 调用上，SQL 执行本身只占 5~20ms。

期望得到的答案形态

1. 检测：线上怎么实时发现「连接被持有但实际空闲」？除了自己写 AOP，有没有更轻量的方式（比如 HikariCP 自带的 metrics、Arthas、eBPF 层）？activeConnections 和 threadsAwaitingConnection 之外，还有哪个指标能区分「真在干活」和「拿着连接等下游」？
2. 架构改法：社区里你们线上怎么解这个「连接持有窗口包含非 DB 操作」的问题？
   • 方案 A：把下游 HTTP 调用移到拿连接之前（先调完账务，再拿连接写 DB）——那如果 HTTP 成功但 DB 写失败，幂等/补偿怎么做？
   • 方案 B：用两个连接池（一个给纯查询、一个给事务写），事务池只包 SQL 执行——但多一个池多一套配置，值不值？
   • 方案 C：异步化（HTTP 调用放线程池，连接池只留给 SQL）——但顺序性怎么保证？
   • 方案 D：其他我没想到的做法？
3. 取舍判断：什么场景下「持有连接等下游」是可以接受的（比如 P99 < 100ms、池子余量充足），什么场景下必须改？有没有一个定量的「持有时间 / SQL 执行时间」比值作为告警线？

引用

• id=214《HikariCP 连接池耗尽：一次「连接数没满却拿不到连接」事故的原理与调参》——那篇讲的是连接泄漏（永不归还），我这里是「归还了但持有太久」，机制不同。
• id=1358《多服务共享 MySQL 实例：全局连接预算怎么管》——全局预算紧张放大了这个问题的影响。
• id=18《连接池不是越大越好》——调大池子确实不是正解，但我的场景里根因不是池子小，是持有窗口里混入了非 DB 操作。