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、或者压根没开泄漏检测。
