HikariCP报连接超时根本原因是活跃连接长期≥最大连接数且新请求排队超时常见于慢查询、事务未提交、连接泄漏或maximumPoolSize过小需结合监控、日志、SQL分析和合理参数配置综合排查。为什么 HikariCP 报 Connection is not available, request timed out after 30000ms这不是数据库挂了而是连接池彻底没连接可用了。根本原因是活跃连接数长期 ≥ 最大连接数maximumPoolSize且新请求排队超时。常见于慢查询堆积、事务未及时提交、连接泄漏或 maximumPoolSize 设得太小。实操建议先查当前活跃连接SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND ! Sleep;确认是否真有大量长事务或卡住的查询检查应用日志里是否有未关闭的 Connection、Statement 或 ResultSet —— 尤其在异常分支里漏掉 close()HikariCP 默认不自动回收泄漏连接需显式开启leakDetectionThreshold60000单位毫秒设太低会误报太高起不到作用别盲目调大 maximumPoolSizeMySQL 默认 max_connections151超过会直接拒绝新连接Java 端线程数也会上涨可能触发 GC 压力maximumPoolSize 和 minimumIdle 怎么设才不翻车这两个值不是拍脑袋定的。设高了压垮 DB设低了并发一上来就排队设太低的 minimumIdle 会导致连接频繁创建销毁增加握手开销。实操建议先估算业务峰值 QPS 和平均响应时间比如 200 QPS × 0.2s 40 并发连接需求再留 20%~30% 余量 → maximumPoolSize 初值可设为 50~60minimumIdle 建议设为 maximumPoolSize 的 70%~100%避免流量突增时疯狂建连但若 DB 实例资源紧张可降到 50%靠 connectionTimeout 控制等待注意 MySQL 的 wait_timeout默认 28800 秒和 HikariCP 的 idleTimeout默认 600000ms要错开否则空闲连接可能被 DB 主动断开而池子还傻等它“健康”启用 testOnBorrowfalse默认改用 connectionTestQuerySELECT 1 validationTimeout3000更轻量Spring Boot 里怎么验证连接池真在按预期工作光看配置文件不等于生效。很多项目配了 maximumPoolSize结果启动日志里显示的仍是默认值 10 —— 因为属性名写错、配置没加 spring.datasource.hikari. 前缀或者被其他 auto-configuration 覆盖了。 唱鸭 音乐创作全流程的AI自动作曲工具集 AI 辅助作词、AI 自动作曲、编曲、混音于一体