HikariCP connectionTimeout 频繁触发，如何量化区分「连接真泄漏」vs「被慢 SQL 占满」？

背景 我负责一个订单写入服务：Spring Boot 3.2 + JDK 17 + HikariCP 5.1 + MySQL 8.0，单实例 8C16G，前置 4 实例。核心链路是「接收下单 → 写主库 → 发事件」。HikariCP 关键配置：maximumPoolSize=20、connectionTimeout=3000ms、leakDetectionThreshold=60000ms。

现象 白天平稳（QPS ~800，P50 20ms），晚高峰（QPS ~2000，P50 30ms）时约 1% 的请求在 3s 后抛 SQLTransientConnectionException: Connection is not available, request timed out after 3000ms。同时 leakDetectionThreshold 没有触发，日志里始终看不到 Apparent connection leak detected。

已尝试的排查与结果

1. 高峰期抓 SHOW PROCESSLIST：最慢一条是带 IN 子查询的批量 UPDATE，耗时 2.8s；但没有看到连接长时间处于 Sleep 状态。
2. 把 maximumPoolSize 从 20 提到 50：超时比例反而从 1% 升到 4%——我怀疑是慢 SQL 把池占满后，更多并发进来一起排队，越扩越堵。
3. 把 leakDetectionThreshold 降到 30000ms 复现晚高峰：依然没有泄漏告警。
4. 用 JFR 抓 CPU + 锁竞争：没看到明显的 synchronized 热点。

我卡住的点 「连接拿了没还（真泄漏）」和「连接被慢 SQL 合法占用、池被占满导致新请求等不到（伪超时）」这两种情况，表象都是 connectionTimeout，但处理路径完全不同：前者要查代码里的 try-with-resources / finally close / 异常分支漏 close，后者要治慢 SQL 或重估池大小。我需要一个能直接判别当前属于哪种的可观测手段。

期望得到的答案形态

• 一个可操作的判别方法：看 HikariCP 的哪个内部指标 / JMX MBean / 日志字段，怎么读数能区分「pending 队列堆积（池被慢 SQL 占满）」vs「连接持有时间异常长（真泄漏）」；最好带具体的 MBean 名或 SQL/命令。
• 「慢 SQL 占满池」场景下的一组推荐参数组合（connectionTimeout / leakDetectionThreshold / maximumPoolSize / maxLifetime）和理由，为什么不是越大越好。
• 如果社区有人踩过完全一样的坑，欢迎贴当时的现象、最终解法和复盘链接。