真正卡住系统的往往是连接被事务长时间持有而非sql执行慢；需区分获取连接等待、sql执行、连接持有三阶段，重点排查@transactional中混入非db操作导致连接空占。
别只盯着SQL执行时间——慢SQL堵塞连接池，真正卡住系统的往往不是那100ms的查询，而是它背后被事务裹挟着“空占连接”的2.8秒。
先看清楚：连接池耗尽 ≠ SQL慢，而是连接被长时间持有
一次数据库访问包含三个独立时间段：
- 获取连接等待时间：线程在连接池里排队等空闲连接的时间；
- SQL执行时间：数据库内部真正干活的时间（慢SQL平台只报这个）；
- 连接持有时间：从借出连接到归还连接的总时长，包括远程调用、计算、休眠等非数据库操作。
当@Transactional包裹了HTTP调用或文件处理，连接就一直不归还。哪怕SQL只跑100ms，连接可能被占3秒——池子30个连接，QPS超10就会排队，高峰直接雪崩。
快速定位：查日志 + 查连接状态 + 查事务边界
不用等故障复现，现在就能做三件事：
- 查应用日志关键词：“connection wait timeout” 或 “HikariPool-1 - Connection is not available”，确认是否真卡在获取连接环节；
- 连上数据库执行：SHOW PROCESSLIST;，重点看State列是否大量显示"Sleep"且Time值持续增长（说明连接已借出但未归还）；
- 翻代码找所有@Transactional方法，特别检查里面是否混入了：HTTP调用、消息发送、本地计算、Thread.sleep()等非DB操作。
验证根因：模拟压测 + 拆分事务
写一个最小复现脚本：
- 构造一个带@Transactional的方法，里面先查库，再sleep(2000)，最后更新；
- 用JMeter并发20请求，观察连接池活跃数是否迅速打满、后续请求是否排队超时；
- 把sleep挪到@Transactional之外，再压测——如果连接不再堆积，就100%确认是事务范围过大。
这种验证比猜配置更可靠，5分钟就能闭环。
修复动作要精准：拆事务 + 加超时 + 补监控
不是盲目调大maxPoolSize，而是让连接“该借就借、该还就还”：
- 把远程调用、重试逻辑、结果组装等非DB操作，从@Transactional方法中剥离出来；
- 对必须保一致性的场景，改用@Transactional(propagation = Propagation.REQUIRES_NEW)控制粒度；
- 给HTTP客户端配合理超时（如OpenFeign的readTimeout=2000），避免一个接口挂掉拖垮整个事务；
- 加一条Prometheus指标：hikaricp_connections_active{application="xxx"}，设置告警阈值为maxPoolSize × 0.8。
