maxLifetime设为0表示连接永不过期，但MySQL仍按wait_timeout（默认28800秒）主动关闭空闲连接，HikariCP无法感知，导致复用已关闭连接时抛CommunicationsException。
为什么 maxLifetime 设为 0 会让连接在 MySQL wait_timeout 后静默失效
MySQL 默认 wait_timeout=28800（8 小时），而 HikariCP 的 maxLifetime 默认是 30 分钟（1800000 毫秒）。若设为 0，表示“永不过期”，但实际连接仍受 MySQL 侧限制——超时后 MySQL 主动断开，HikariCP 却不感知，下次复用该连接就会抛 CommunicationsException: Connection closed 或 SQLException: Connection is closed。
正确做法是让 maxLifetime 比 wait_timeout 小至少 2–5 分钟，例如：
spring.datasource.hikari.max-lifetime=25200000 // 7 分钟，对应 MySQL wait_timeout=300s（5分钟）时更稳妥
-
maxLifetime必须严格 wait_timeout，否则必然出现“连接已关闭但池未清理” - 不要依赖
connection-test-query（已废弃），改用connection-test-query对应的现代替代项connection-test-query已被移除，应使用connection-init-sql或更可靠的validation-timeout+connection-test-query（仅限旧版）→ 实际应启用connection-test-query？错：HikariCP 5.x 起只认connection-test-query？不，最新版（5.0+）已完全移除该配置，验证靠connection-init-sql和validation-timeout配合leak-detection-threshold - 真正生效的健康检查靠
connection-init-sql=SELECT 1（轻量）+validation-timeout=3000（毫秒）
minimumIdle 设太高反而引发连接风暴和 CPU 尖刺
很多人误以为“多保活些连接 = 更快响应”，于是把 minimumIdle 设成 20、50 甚至等于 maximumPoolSize。结果是：应用启动/低峰期，HikariCP 主动维持大量空闲连接，MySQL 线程数暴涨，Threads_connected 居高不下；同时 HikariCP 内部定时线程频繁扫描连接有效性，CPU 使用率异常升高。
真实建议：
- 生产环境
minimumIdle建议设为maximumPoolSize的 1/4～1/3，且绝对值不超过 10（如maximumPoolSize=30→minimumIdle=8） - 若业务有明显波峰波谷（如定时批处理），可配合
allow-pool-suspension=true+ 外部触发缩容（但需自行管理，HikariCP 不提供 API） - 监控关键指标：
HikariPool-1 - Pool stats (total=30, active=2, idle=28, waiting=0)，idle 长期 > 90% 说明minimumIdle过高
connection-timeout 太短会导致正常慢查询被误杀
connection-timeout 控制的是“从池里拿连接”的最大等待时间，不是 SQL 执行超时。设成 300（毫秒）看似激进，但一旦数据库瞬时延迟升高（如主从同步抖动、临时锁表），大量线程会在获取连接阶段就抛 HikariPool$ConnectionTimeoutException: Timeout elapsed before connection could be acquired，掩盖了真实瓶颈。
合理设定原则：
- 观察 P95 获取连接耗时（可通过 HikariCP 的
metricsTrackerFactory或 Micrometer 暴露的hikaricp_connection_acquire_seconds），设为 P99 + 200ms - 常规 OLTP 场景建议 1000–3000 毫秒；混合 OLAP 查询的系统，可放宽到 5000 毫秒
- 绝不设
0或-1（无限等待），这会拖垮整个线程池，引发雪崩
MySQL JDBC URL 必须加 useServerPrepStmts=true&cachePrepStmts=true
HikariCP 自身不处理预编译缓存，它依赖 JDBC 驱动层。MySQL Connector/J 默认关闭服务端预编译（useServerPrepStmts=false），即使你写了 PreparedStatement，驱动仍走客户端模拟，无法复用执行计划，也浪费网络 round-trip。
必须在 JDBC URL 中显式开启：
jdbc:mysql://localhost:3306/mydb?useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=250&prepStmtCacheSqlLimit=2048
-
useServerPrepStmts=true是前提，否则cachePrepStmts无效 -
prepStmtCacheSize建议 200–500（根据 SQL 模板数量调整），太大反而 GC 压力高 -
prepStmtCacheSqlLimit控制缓存的 SQL 长度上限，2048 覆盖绝大多数场景；太小会导致长 SQL 无法缓存 - 注意：Spring Boot 2.4+ 默认使用 MySQL 8.0+ 驱动，该配置依然有效；但若用 MariaDB 驱动，则对应参数名不同（
cachePrepStmts→cachePrepStmts一致，但需确认驱动版本）
HikariCP 的调优从来不是调几个数字，而是对 MySQL 状态、JDBC 行为、应用流量模式三者的交叉校准。最容易被跳过的其实是 wait_timeout 和 maxLifetime 的数值对齐，以及 JDBC URL 里那串不起眼的 & 参数——它们不出问题时无声无息，一出就是大面积连接失败或性能毛刺。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
