SQL连接池参数需依业务场景权衡：高并发防耗尽、长事务控占用、低流量避浪费；maxPoolSize不得超过数据库max_connections上限，建议设为60%~80%并预留余量。
SQL连接池参数配置不是堆数值，而是根据业务特征做取舍——高并发场景要防连接耗尽，长事务场景得控连接占用，低流量系统反而要避免空闲连接浪费资源。
核心参数必须对齐数据库承载力
最大连接数（maxPoolSize）不能超过数据库服务器的连接上限，否则大量连接请求会直接被拒绝。比如MySQL默认max_connections=151，若应用设为200，超出的50个请求将排队或失败；PostgreSQL则需留意superuser_reserved_connections预留值。建议将maxPoolSize设为数据库总连接数的60%~80%，并预留余量给其他服务或DBA操作。
- 查看MySQL当前连接上限：
SHOW VARIABLES LIKE 'max_connections'; - PostgreSQL检查：
SHOW max_connections; - 连接池实际可用连接 = maxPoolSize − minIdle（最小空闲数），这个差值决定突发流量缓冲能力
空闲连接管理：minIdle与idleTimeout协同控制
minIdle不是“越多越好”。设太高会导致应用启动后立即占用一批连接不释放，推高数据库负载；设太低又会让突发请求频繁创建新连接，增加握手开销。推荐值：QPS稳定在100以下可设为5~10；QPS 500+建议15~30，并配合idleTimeout（如10分钟）及时回收长期空闲连接。
- Druid示例：
minIdle="10" maxActive="50" timeBetweenEvictionRunsMillis="60000" - HikariCP更简洁：
minimum-idle=10, idle-timeout=600000, max-lifetime=1800000 - 注意：idleTimeout必须小于数据库的wait_timeout（MySQL默认8小时），否则连接可能被服务端主动断开
连接有效性验证：testOnBorrow还是validationQuery？
高频校验（如每次获取连接都执行SELECT 1）会显著拖慢吞吐。现代连接池（HikariCP、Druid 1.2+）推荐用connection-test-query + test-while-idle组合：只在空闲连接被取出前检测，既保障可用性，又避免运行时开销。验证SQL务必轻量，MySQL用SELECT 1，PostgreSQL用SELECT 1或SELECT NOW()，禁用带函数或表查询。
- HikariCP默认启用
connection-test-query，无需额外配置 - Druid需显式设置：
testWhileIdle="true" validationQuery="SELECT 1" - Oracle注意：要用
SELECT 1 FROM DUAL，否则验证失败
超时与重试：failFast与connectionTimeout的实用配比
connectionTimeout（获取连接超时）建议设为2~5秒：太短导致正常排队被误判失败，太长让线程卡住影响整体响应。搭配failFast=true可快速暴露连接池枯竭问题，便于监控告警；但生产环境慎用，避免雪崩扩散。对于偶发网络抖动，可开启maxLifetime（如30分钟），强制连接定期重建，规避TCP半开连接或服务端异常断连。
- 典型组合：
connection-timeout=3000, max-lifetime=1800000, leak-detection-threshold=60000 - leak-detection-threshold（连接泄漏检测）设为60秒，能捕获未close的Connection，防止连接缓慢耗尽
- 避免设置loginTimeout（JDBC层），它由连接池统一管控更可靠
不复杂但容易忽略：所有参数都要和真实压测结果对照调优，没有银弹配置。上线前用JMeter模拟峰值QPS，观察连接池活跃/空闲曲线、平均获取时间、拒绝率三项指标，再微调。
