你有没有遇到过这种情况：压测的时候系统表现很好，上了生产环境却频繁出现卡顿？监控看一圈，CPU不高、内存不爆、磁盘IO正常，数据库也没有慢查询。最后翻应用的连接池配置，发现最大连接数只有10。
这不是段子，是我们上周处理的一个真实案例。客户的订单系统在高峰期并发量达到200，但连接池最大连接数只有10，剩下的请求全在排队等连接。响应时间从200毫秒飙到5秒，用户体验直接崩盘。
连接池配置的两个核心参数
第一个是minimumIdle（最小空闲连接数）。很多人把这个值设得特别小，甚至设成0，觉得按需创建更省资源。实际上连接的创建和销毁本身就有开销，频繁建连会让数据库压力增大。建议设为日常平均并发的50%-70%，保证基础流量不触发建连。
第二个是maximumPoolSize（最大连接数）。这个值不是越大越好。MySQL的max_connections通常是151，如果应用配了200个连接，超出部分直接被数据库拒绝。而且连接太多会导致上下文切换开销增大，反而降低吞吐。经验值是：单个应用实例的连接数不超过数据库max_connections的20%。
容易忽略的连接泄漏检测
连接泄漏是另一个隐形杀手。代码里借了连接忘了还，连接池里的可用连接越来越少，最终耗尽。HikariCP提供了leakDetectionThreshold参数，建议设为30000毫秒。连接借出超过30秒未归还，日志里就会有告警。出了告警赶紧排查对应的调用链，定位泄漏点。
还有一个参数是connectionTimeout，控制获取连接的最大等待时间。默认30秒太长了，用户早就等不及了。建议设为3-5秒，拿不到连接快速失败，触发降级逻辑，比让用户干等强。
检查清单
第一，确认连接池最大连接数与数据库max_connections匹配。第二，开启连接泄漏检测。第三，设置合理的获取超时时间。第四，定期监控连接池的使用率，持续高位说明需要扩容了。把这些做完，连接池就不会成为性能瓶颈。