连接池大小需匹配实际并发与db承载能力：按峰值qps×平均耗时得活跃连接数，再×2–3设maxpoolsize；minidle为30%–50%；须设leakdetectionthreshold；注意db端max_connections限制。
连接池大小设多少才不拖慢应用又不浪费资源
数据库连接池不是越大越好，也不是越小越省；它得贴着你的实际并发请求节奏和数据库承载能力来调。设大了，空闲连接占内存、DB 端线程耗尽、甚至触发 too many connections 错误；设小了，请求排队等待，wait_timeout 被触发，日志里满屏 Connection wait timeout。
实操建议：
- 先看真实峰值 QPS 和平均单次查询耗时（比如 50 QPS × 200ms = 平均需约 10 个活跃连接），再乘以 2–3 倍作为初始
maxPoolSize（如 HikariCP 的maximum-pool-size） - 把
minIdle设为maxPoolSize的 30%–50%，避免冷启动后大量连接懒创建带来的延迟毛刺 - 务必打开
leakDetectionThreshold（如 60000 毫秒），能早发现没 close 的Connection或未释放的ResultSet - PostgreSQL 要注意
max_connections默认仅 100，MySQL 默认 151——你的池子总大小不能跨实例超这个数，否则直接被 DB 拒绝
HikariCP 里 connection-timeout 和 validation-timeout 怎么配
这两个超时不是“越短越好”，而是要匹配你的网络稳定性、DB 健康检查开销和业务容忍度。设得太短，健康检测频繁失败，连接被误剔除；设得太长，故障时卡住整个池子。
实操建议：
-
connection-timeout推荐 30000（30 秒）：覆盖大多数网络抖动 + DB 临时负载高峰，低于 1000 容易把正常慢查询当故障 -
validation-timeout必须 ≤connection-timeout，且建议设为 3000（3 秒）：验证语句（如SELECT 1）本身不该耗这么久，超时说明 DB 已失联或严重卡顿 - 别用
testOnBorrow（已废弃），改用connection-test-query+validation-timeout，且确保验证 SQL 在目标 DB 语法下有效（MySQL 用SELECT 1，PostgreSQL 用SELECT 1也行，但 Oracle 得用SELECT 1 FROM DUAL）
为什么加了连接池，还是频繁报 “Connection is closed”
这不是池子坏了，大概率是代码层提前关了连接，或者事务没正确结束，导致连接归还时已被标记为 invalid。HikariCP 默认会在归还时做轻量验证，一验就崩。
常见错误现象：
- 手动调用了
connection.close()后又试图用同一对象执行statement.execute() - Spring @Transactional 方法里用了 try-catch 吞掉异常，但没加
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，导致事务未回滚、连接带脏状态还池 - MyBatis 的
SqlSession没走 Spring 管理，自己 new 出来又没 close，底层Connection实际没释放
实操建议：
- 永远用 try-with-resources 包裹
Connection/Statement/ResultSet，别信“我肯定记得 close” - 在 HikariCP 配置里加
isolate-internal-queries=true和allow-pool-suspension=true，让内部验证更稳 - 开启
log-level=DEBUG并 grepHikariPool日志，重点看Added connection和Removed connection是否成对出现
Druid 和 HikariCP 切换时最容易漏掉的三件事
不是改个依赖、换几个配置项就完事。Druid 自带监控页面、SQL 防注入、WallFilter，HikariCP 什么都没有——这些功能得你自己补，否则上线就丢能见度。
实操建议：
- Druid 的
stat-view-servlet对应功能，HikariCP 得靠 Micrometer + Prometheus 暴露hikaricp.connections.active等指标，漏配就等于瞎跑 - Druid 的
filter: wall能拦截危险 SQL，HikariCP 不处理 SQL 内容，必须在 MyBatis 的Interceptor或应用网关层补规则 - Druid 默认开启
removeAbandonedOnBorrow=true，HikariCP 对应的是remove-abandoned-on-maintenance+abandoned-timeout，参数名和行为逻辑都不同，照抄配置会失效
池子本身只是个容器，真正决定稳定性的，是你怎么用它、怎么观察它、以及出问题时能不能快速定位到是代码漏关、DB 卡死，还是配置拍脑袋。别只盯着 maximum-pool-size 调数字。
