连接池配置错误的典型表现
应用启动失败、数据库连接超时、大量
Connection refused或
Too many connections错误，往往不是 MySQL 服务端问题，而是客户端连接池配错了。最常见的是把连接池最大值设得远超 MySQL 的
max_connections，或空闲连接回收策略缺失导致连接长期滞留。
maxActive（旧版 DBCP）或
maximumPoolSize（HikariCP）设为 200，但 MySQL 的
max_connections只有 151 → 启动后部分请求直接失败
minIdle设为 50 且未配
idleTimeout→ 应用空闲时仍维持 50 个空闲连接，MySQL 端堆积大量
Sleep状态连接 使用 HikariCP 却漏配
connection-test-query（MySQL 8.0+ 必须用
isValid()，不再支持该参数）→ 连接假死无法自动剔除
HikariCP 关键参数与 MySQL 兼容性
HikariCP 是当前主流选择，但它的行为和 MySQL 的握手、超时机制强耦合，参数不匹配会引发静默故障。
connectionTimeout建议设为 30000（30 秒），低于 MySQL 的
wait_timeout（默认 28800 秒），避免连接池等一个已关闭的连接
validationTimeout必须 ≥ 3000（3 秒），否则健康检查可能被中断，尤其在高延迟网络下
keepaliveTime（仅 HikariCP 3.4.5+）推荐设为 300000（5 分钟），需小于 MySQL 的
wait_timeout，触发主动保活
driver-class-name必须用
com.mysql.cj.jdbc.Driver（MySQL 8+），旧版
com.mysql.jdbc.Driver在连接池复用场景下可能出现时区或 SSL 握手异常
spring:
datasource:
url: jdbc:mysql://localhost:3306/test?serverTimezone=UTC&useSSL=false
driver-class-name: com.mysql.cj.jdbc.Driver
hikari:
maximum-pool-size: 20
minimum-idle: 5
connection-timeout: 30000
idle-timeout: 600000
max-lifetime: 1800000
keepalive-time: 300000
validation-timeout: 3000
DBCP2 和 Druid 的易错点对比
DBCP2 已基本淘汰，Druid 在国内仍有使用，但两者对 MySQL 的连接生命周期管理逻辑不同，错误配置后果差异明显。
DBCP2 的maxWaitMillis默认 -1（无限等待），线上必须显式设为 ≤ 5000，否则线程卡死无报错 Druid 的
testWhileIdle开启后，
timeBetweenEvictionRunsMillis若设得太小（如 1000），会高频执行
SELECT 1，加重主库压力 Druid 的
phyTimeoutMillis（物理连接超时）若小于 MySQL 的
connect_timeout（默认 10 秒），会导致新建连接被误判为失效 所有连接池都应禁用
autoReconnect=true（URL 参数），它在连接池中不可靠，反而掩盖真实网络问题
如何验证连接池是否真正生效
光看配置文件没用，得从三个层面交叉验证：应用日志、连接池内部指标、MySQL 实时状态。
启动时确认日志出现类似HikariPool-1 - Starting...而非
DBCP PoolableConnectionFactory（说明实际加载的是预期连接池） 暴露 Actuator endpoint（如
/actuator/metrics/hikaricp.connections.active）观察峰值是否接近
maximum-pool-size登录 MySQL 执行
SHOW PROCESSLIST;，过滤出对应应用用户，确认连接数稳定在
minimum-idle～
maximum-pool-size区间，且无大量
Sleep超过
wait_timeout
MySQL 的连接池调优不是设几个数字的事，关键在于让连接池的“心跳”节奏和 MySQL 的超时机制对齐；稍有错位，就会在流量低谷时悄无声息地积累坏连接，到高峰时集中爆发。
