HikariCP连接池空闲却频繁创建销毁连接，主因是minimumIdle过低或idleTimeout过短；应设minimumIdle=maximumPoolSize、idleTimeout小于DB超时、启用keepaliveTime保活，并配置leakDetectionThreshold防连接泄漏。
连接池一直空闲却频繁创建销毁连接
这是 HikariCP 配置里最常被忽略的信号：连接没被复用，说明连接池没真正“活”起来。根本原因通常是 minimumIdle 设得太低（甚至为 0），或者 idleTimeout 过短，导致空闲连接被快速回收。
实操建议：
-
minimumIdle建议设为和maximumPoolSize相同（比如都设为 20），避免冷启动抖动；设为 0 时，HikariCP 实际不会维持任何空闲连接 -
idleTimeout默认 10 分钟（600000ms），若数据库侧有 5 分钟连接超时，这里必须小于它（例如设为 240000），否则连接会被 DB 主动断开，而 HikariCP 还以为它活着 - 启用
keepaliveTime（>= HikariCP 3.2.1）并设为比idleTimeout小一点的值（如 200000），让连接池主动发心跳保活，避免被中间设备或 DB 层 silent kill
应用刚启动就报 “Connection is not available”
这不是数据库扛不住，而是连接池初始化太慢，或初始连接验证失败后没重试。典型表现是第一个请求卡住几秒，然后抛出 java.sql.SQLTimeoutException: Timeout after 30000ms of waiting for a connection。
实操建议：
- 确认
connectionTestQuery已废弃，改用connectionInitSql或更推荐的connectionTestQuery的替代方案——直接配validationTimeout+ 启用initializationFailTimeout -
initializationFailTimeout设为 -1（默认），表示初始化失败不阻塞启动；但若想严格校验，可设为正数（如 3000），失败则抛异常终止 - 避免在
connectionInitSql里执行复杂查询；简单用SELECT 1即可，且确保该 SQL 在目标数据库语法合法（MySQL 是SELECT 1，不是SELECT 1;分号会报错）
高并发下大量线程卡在 getConnection() 等待
这说明连接池已满，新请求排队，但排队时间又没控制好。关键不是盲目调大 maximumPoolSize，而是看是否真需要那么多连接，还是 SQL 慢、事务长、连接没及时归还。
实操建议：
-
connectionTimeout默认 30 秒，线上建议压到 1–3 秒（如 2000），避免业务线程长时间挂起；超时后应快速失败，而不是让用户干等 - 检查是否有未关闭的
ResultSet/Statement，导致连接无法归还；开启leakDetectionThreshold（如 60000，单位毫秒），HikariCP 会在连接疑似泄漏时打 WARN 日志 -
maximumPoolSize不宜超过数据库最大连接数的 70%；MySQL 默认max_connections=151，那 HikariCP 最多配 100，留余量给后台任务或 DBA 操作
MySQL 8.0+ 使用 cachingSha2Password 插件后连接失败
错误信息通常是 Public Key Retrieval is not allowed 或 Could not connect: invalid authorization plugin。这不是连接池问题，是 JDBC 驱动与 MySQL 认证插件不兼容导致的。
实操建议：
- JDBC URL 必须显式加参数：
&allowPublicKeyRetrieval=true&useSSL=false（开发环境），生产环境应配 TLS 并用serverRSAPublicKeyFile - 驱动版本必须 ≥
mysql-connector-java 8.0.15；低于此版本即使加参数也无效 - 如果无法升级驱动，临时降级 MySQL 用户认证方式：
ALTER USER 'xxx'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';，但仅作过渡
leakDetectionThreshold 和 keepaliveTime ——它们不解决“连不上”，但能提前暴露“连上了却没还”的真实问题。 
