关键在于平衡连接数：最大连接数须低于数据库上限（如MySQL默认151），推荐值为QPS×平均耗时×1.5～2且取小值；空闲连接需动态管理，minIdle保障突发响应，idle_timeout与maxLifetime避免资源浪费。
SQL 连接池参数配置的关键，是让连接数“够用、好用、省着用”——既扛住业务峰值，又不压垮数据库，还不浪费资源。
最大连接数（maxPoolSize / max_connections）要卡在数据库上限内
这个值绝不能超过数据库允许的总连接数，否则请求直接被拒绝：
- MySQL 查看上限：
SHOW VARIABLES LIKE 'max_connections';，默认常为151；云数据库如阿里云RDS可能设为1000，但实际建议连接池只用其60%~70% - PostgreSQL 查看：
SHOW max_connections;，注意预留superuser_reserved_connections给DBA操作 - SQL Server 中通过
sp_configure 'user connections'查看和调整 - 推荐初始值：单机QPS × 平均SQL耗时（秒）× 1.5～2，再与数据库上限比对取小值。例如QPS=200、平均耗时0.08s → 基础需16个，缓冲后设为30，若MySQL上限是200，则30安全；若上限仅50，也仍留有余量
空闲连接管理（minIdle / idle_timeout / maxLifetime）要动态平衡冷启动与资源占用
空闲连接不是越多越好，也不是越少越省事：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- minIdle（最小空闲数）：保障突发流量来时“秒级响应”。QPS
-
idleTimeout（空闲超时）：回收长期不用的连接，避免被防火墙或中间件断连。建议设为300~600秒（5~10分钟），且必须小于数据库的
wait_timeout（MySQL默认8小时，PostgreSQL默认1小时） - maxLifetime（最大生命周期）：强制刷新老化连接，防内存泄漏或TCP僵死。建议1800~3600秒（30~60分钟），HikariCP默认1800000ms即30分钟
连接有效性验证（validationQuery / testWhileIdle）要轻量且精准
每次取连接都校验会拖慢吞吐，只在必要时检测才合理：
- 禁用
testOnBorrow（每次获取都查），改用testWhileIdle+ 轻量验证语句 - MySQL 用
SELECT 1；PostgreSQL 用SELECT 1或SELECT NOW()；Oracle 必须用SELECT 1 FROM DUAL - Druid 需显式开启：
testWhileIdle="true" validationQuery="SELECT 1"；HikariCP 默认启用，无需额外配 - 验证SQL严禁含函数调用（如
SELECT SLEEP(1)）或表查询，避免副作用和性能开销
超时与重试策略（acquireTimeout / connectionTimeout / failFast）要兼顾稳定与可观测性
超时不是越短越好，而是让问题暴露得及时、可控：
- acquireTimeout（获取连接超时）：建议2~5秒。太短（如500ms）易误判正常排队为失败；太长（如30秒）会让线程长时间阻塞，拖垮整个接口
-
failFast：设为
true可快速失败并触发告警，适合灰度或监控场景；生产环境慎用，避免因瞬时高峰引发雪崩式失败扩散 - SQLx、HikariCP 等现代池支持异步预热和连接健康探测，可配合指标监控（如活跃连接数、平均等待时间、创建频次）做动态调优
