HikariCP 20 个连接全挂在一条慢 SQL 上 接口为什么排队 30 秒

早上九点开始接口大量超时，HikariPool-1 打印 Connection is not available request timed out after 30000ms，active 一直是 20，idle 是 0。数据库 CPU 只有 15%。日志里能对上时间点，这种反而好排。

二十个连接全被几条跑十几秒的查询占着，后面的请求只能排队等连接。瓶颈不是连接数，是单条 SQL 的持有时长，加连接只会让数据库多扛几份同样的慢查询。这一点先确认清楚，后面就不用反复试。

SELECT id, user, time, state, info
FROM information_schema.processlist
WHERE command = 'Query' AND time > 5
ORDER BY time DESC;

「HikariCP 慢 SQL 占满」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。

别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。

处理上按这个顺序：抓 active 连接上正在跑的 SQL 看 processlist 的 time 字段；给慢 SQL 补索引或者改查询 把单次耗时压下来；连接池加 leakDetectionThreshold 超时后打印堆栈；连接超时按 P99 设 不要一律三十秒。

结果对不对很好判断，active 回落到个位数 等待队列消失 接口不再报 Connection is not available。