数据库连接池性能优化关键在于合理配置与规范使用：需按公式或压测设最大连接数，设最小空闲连接，确认 db 限制；避免 connection 长期持有，确保及时关闭；启用健康检查与主动清理；并监控活跃 / 空闲连接及获取耗时等指标。
数据库连接池用得不好，性能瓶颈往往就出在这儿。关键不是堆更多连接，而是让每个连接都用得高效、及时释放、不拖慢应用。
合理设置连接池大小
连接数不是越多越好。过大会加重数据库负担，过小又容易排队等待。经验值是：连接池最大值 ≈（核心数 × 2）+ 磁盘数（适用于 IO 密集型场景）；更稳妥的做法是结合压测结果动态调整。比如 Web 服务 QPS 为 500，平均 SQL 耗时 200ms，理论并发连接需求约 100，再加 20% 余量，初始设为 120 较合理。
- 最小空闲连接数建议设为 5–10，避免冷启动时频繁创建连接
- 最大连接数上线前务必和 DBA 确认数据库允许的最大连接数（如 MySQL 默认 151）
- 启用连接池的“自动伸缩”（如 HikariCP 的 maximumPoolSize + minimumIdle 配合
缩短连接生命周期，避免长连接滥用
连接不是“借了就一直拿着”，而应遵循“即用即取、用完即还”。业务代码中常见错误是把 Connection 对象跨方法、跨事务长期持有，甚至塞进 ThreadLocal 里复用——这会阻塞连接回收，导致池子“假性枯竭”。
- 确保所有 try-with-resources 或显式 close() 调用覆盖全部分支（含异常路径）
- 禁用手动 setAutoCommit(false) 后忘记提交 / 回滚，这类连接会被标记为“未归还”并超时强制回收
- 查询类操作尽量走只读连接（如配置readOnly=true），部分连接池可据此优化路由或复用策略
启用健康检查与主动清理
网络闪断、数据库重启、防火墙超时都会让连接池里的连接变成“僵尸连接”。靠等待报错再剔除太被动，应主动探测。
- 开启 connection-test-query（如SELECT 1）或使用 JDBC 4.0+ 的isValid() 接口
- 设置validation-timeout（如 2 秒）防止检测卡住线程
- 配置idle-timeout（如 10 分钟）和max-lifetime（如 30 分钟），强制淘汰老旧连接，避免因数据库端 kill idle 连接引发异常
监控连接池状态，问题早发现
光靠日志看不出连接是否打满、是否频繁创建销毁。必须接入实时指标：
- 关注activeConnections、idleConnections、pendingAcquires（等待获取连接的线程数）——若后者持续>0，说明池子已饱和
- 记录connection-acquire-time（获取连接耗时），突增意味着连接竞争加剧
- HikariCP 提供getMetricsTrackerFactory()，Druid 支持 JMX 或内置监控页面，别只当摆设
