SQL 连接池 maxLifetime 与 idleTimeout 的配置原则与泄漏防控

maxlifetime设为0或负数会导致连接永不过期，引发数据库断连后连接池仍误用失效连接，抛communicationsexception；须小于数据库wait_timeout并留30秒缓冲，如db为28800秒则设28740秒。

maxLifetime 设为 0 或负数会怎样

设为 0 或负数（如 -1）意味着连接永不过期，这在生产环境极危险：数据库可能主动断开空闲太久的连接（比如 mysql 默认 wait_timeout=28800 秒），而连接池还把它当活连接用，下一次 getConnection() 后执行 SQL 就抛 CommunicationsException 或 Connection reset。HikariCP 文档明确建议该值必须小于数据库的超时设置，且留至少 30 秒缓冲。

• maxLifetime 应比数据库 wait_timeout 小 30–60 秒（例如 DB 是 28800，这里设 28740）
• 不能依赖数据库超时兜底——连接池自己得先清理
• postgresql 的 tcp_keepalives_idle 等参数无法替代 maxLifetime，它只管 TCP 层保活，不解决事务未提交、连接被服务端单方面 kill 的问题

idleTimeout 比 maxLifetime 还大？那就白配了

如果 idleTimeout > maxLifetime，连接永远等不到“空闲淘汰”那一步——它会在达到 maxLifetime 时被强制回收。此时 idleTimeout 实际失效。更糟的是，若两者都设得过大（比如都设成 30 分钟），连接池里会堆积大量“看似可用、实则数据库已断”的连接，尤其在低流量时段。

• 推荐组合：maxLifetime=1800（30 分钟），idleTimeout=600（10 分钟）——让空闲连接更早释放，减轻 DB 端连接数压力
• idleTimeout 不影响活跃连接，只对归还后未被借走的连接生效
• HikariCP 要求 idleTimeout 必须 ≤ maxLifetime - 1000，否则启动报错：idleTimeout cannot be greater than or equal to maxLifetime

连接泄漏时，这两个参数根本救不了你

连接没 close 就丢进 finally 块、没用 try-with-resources、或者异步线程里忘了归还——这些泄漏行为会让连接长期被占用，既不空闲也不超期。maxLifetime 和 idleTimeout 对它们完全无效。唯一能暴露问题的是 leakDetectionThreshold（单位毫秒）。

• 设 leakDetectionThreshold=60000，连接被借出超 60 秒未归还，HikariCP 就打 WARN 日志并打印堆栈
• 该阈值不宜设太小（如 5000），否则正常慢查询会被误报；也不宜关掉（0）
• 日志里看到 Connection leak detection triggered，说明代码里有 connection 忘了 close()，不是配置调得不对

MySQL 8.0+ 开启 caching_sha2_password 插件后，maxLifetime 要更保守

该认证插件握手阶段耗时略高，加上连接复用时若刚好卡在 maxLifetime 边界，重连认证失败概率上升。实测中，把 maxLifetime 从 30 分钟缩到 15 分钟，可显著降低首次查询 SQLException: public Key Retrieval is not allowed 类错误。

• 搭配 cachePrepStmts=true 和 prepStmtCacheSize=250 可缓解握手开销
• 不要为了“省连接”硬拉长 maxLifetime，稳定比理论吞吐重要
• 该问题在 mariadb 或旧版 MySQL 上不存在，属于协议层适配细节，容易被忽略

配置不是调参游戏，是跟数据库行为、网络稳定性、代码健壮性一起磨出来的。最常出问题的，从来不是数值本身，而是以为设了就万事大吉，结果漏掉了连接没 close、事务没 commit、或者压根没开泄漏检测。