数据库连接池从频繁超时到稳定运行：政策快报平台的优化之路

2023年有一段时间政策快报平台每天下午都会出现一波“服务慢”的投诉。接口响应时间从200ms飙升到3-5秒有时候直接超时。查了日志发现是数据库连接池在高峰期被耗尽。新的请求拿不到连接只能等待或超时。当时我们的连接池配置是“默认参数”——最大连接数10、超时时间30秒。看起来合理的配置在高峰期根本扛不住。后来我们花了几周时间从连接池配置到代码优化做了一整套改造。接口超时率从5%降到了0.1%以下。今天复盘这个优化过程。一、问题诊断连接池为什么被打满首先我们来理解连接池被打满的完整链路。问题现象高峰期接口响应时间从200ms飙升到3-5秒部分接口直接超时30秒后返回错误数据库CPU使用率并不高30%左右说明不是数据库慢查询导致的问题排查过程查看数据库连接数sql复制下载SHOW PROCESSLIST;发现连接数接近上限100个大量连接处于“Sleep”状态。查看应用日志大量“HikariPool-1 - Connection is not available”错误。这是HikariCP在连接池耗尽时抛出的异常。分析代码发现有两个问题有代码没有正确关闭Connectiontry-with-resources使用不当部分接口执行时间过长5-8秒连接一直被占用根本原因连接没有被及时释放 执行时间长 高峰期请求量大 → 连接池快速耗尽。二、配置优化从默认参数到合理参数优化的起点是调整HikariCP连接池的配置。参数优化前优化后说明maximumPoolSize1030最大连接数根据并发量调整minimumIdle1010最小空闲连接保持不变connectionTimeout300005000超时时间从30秒缩短到5秒快速失败而不是长时间等待idleTimeout600000300000空闲超时从10分钟缩短到5分钟释放不用的连接maxLifetime1800000600000连接最大存活时间从30分钟缩短到10分钟避免长连接被数据库回收核心逻辑连接池配置不是越大越好也不是越小越好。需要根据实际并发量测算。测算方法是峰值QPS × 平均执行时间 需要的连接数。如果峰值QPS为100平均执行时间200ms那么20个连接就足够了。如果平均执行时间较长如5秒则需要100个左右。三、代码优化解决连接泄露找到未正确关闭Connection的代码修复或重构确保所有连接在使用后被关闭。优化前有风险javaConnection conn dataSource.getConnection(); // 执行业务逻辑 // 如果这里抛出异常conn不会被关闭 conn.close();优化后安全javatry (Connection conn dataSource.getConnection()) { // 执行业务逻辑 // 自动关闭 }四、慢查询优化缩短执行时间检查所有超过1秒的SQL加索引、改写法。优化前5-8秒优化后200ms最终效果指标优化前优化后连接池耗尽频率每天3-5次几乎为零接口超时率5%0.1%高峰期响应时间3-5秒200ms数据库连接数100满30-50稳定经验总结连接池配置不是“设置一次就不管了”。需要根据业务增长持续调整。连接泄露是最隐蔽的问题之一。使用try-with-resources是强制规范。配置调整不是优化的终点。优化慢查询、缩短执行时间本质上是在“减少对连接的占用时长”效果比单纯加大连接池更根本。连接池优化的核心思路是先找到“连接不够用”的原因——是配置太小、连接泄露还是执行时间太长。对症下药比盲目调大连接池更有效。