HikariCP 连接池耗尽全站接口超时的根因与解决一个慢接口占着数据库连接不释放连接池很快被耗尽其他接口拿不到连接全站跟着集体超时。本文通过一个「报表慢 SQL 拖垮全站」的真实案例讲清楚连接池耗尽的根因慢 SQL 霸占连接给出 HikariCP 参数配置方法以及「快速失败 无限等待」的应对思路。一、问题案例一个报表接口SQL 写得糙高峰期要跑 30 秒。平时调用不多一直没当回事。直到某天运营在高峰期批量导出报表几十个请求同时打过来。几分钟后全站所有接口集体超时——不光是报表登录、下单、查订单全挂了。看数据库CPU 并不高连接数却打满了。看应用日志全是同一类报错HikariPool-1 - Connection is not available, request timed out after 30000ms二、原理详解连接是稀缺资源慢 SQL 是元凶数据库连接池里就那么多连接HikariCP 默认maximumPoolSize10一个连接同一时刻只能服务一个请求。慢 SQL 占着连接不释放等于把公共资源霸占了慢 SQL30秒× 并发几十个 → 10 个连接全被占满 ↓ 其他接口排队等连接 → 等满 connectionTimeout → 集体超时连接池打满只是表象真正的病根是慢 SQL。不治慢 SQL光加大连接池只是把问题往后拖——连接再多慢 SQL 一多照样打满还会把数据库压垮。三、实战代码治本 合理配置第一步治本修慢 SQL。给报表 SQL 加索引、拆分批、或者改成异步生成。慢 SQL 从 30 秒降到 1 秒以内连接占用时间短了池子自然周转得过来。第二步合理配置 HikariCP。spring:datasource:hikari:maximum-pool-size:20# 最大连接数按公式估别拍脑袋connection-timeout:5000# 拿不到连接 5 秒就失败别让请求干等 30 秒max-lifetime:1800000# 连接最大存活 30 分钟防止被数据库端断开maximum-pool-size经验公式连接数 ≈ (CPU 核数 × 2) 磁盘数。2 核 4G 的机器20 个左右就够connection-timeout调小一点拿不到连接快速失败比排队 30 秒再超时好——至少不会拖垮其他接口max-lifetime设成比数据库的连接超时短一点避免连接被数据库断开后应用还在用。四、延伸快速失败 无限等待连接池耗尽的应对思路不是「把超时调大让请求继续等」恰恰相反——让拿不到连接的请求快速失败配合限流和降级报表这种重接口加限流同时只允许几个请求或者改异步提交任务后立即返回后台慢慢跑前台接口拿不到连接就快速报错别把全站都拖下水。五、总结 避坑建议连接池打满先查慢 SQL那是病根加连接数是治标。连接数按公式估(核数×2)磁盘数别无脑调大。connection-timeout调小拿不到连接快速失败别让请求干等。重接口配限流或异步别让它霸占连接池。我是无羡小剑全栈偏后端的独立开发者。作品集无羡 · 独立开发者作品集如果对你有帮助欢迎点赞、收藏、关注。