minimum-idle应设为maximum-pool-size的1/4至1/3（如max=20则设5～7），低流量服务可取2～3，核心api不低于5；配套需同步配置maximum-pool-size、connection-timeout=30000、idle-timeout=30000、max-lifetime=1800000。
初始连接池大小不是独立配置项，它由最小空闲连接数（minimum-idle）决定。HikariCP 启动时会立即创建 minimum-idle 个连接并保持空闲，这就是实际的“初始连接数”。
minimum-idle 不应随意设为 0。如果设为 0，启动后首次数据库请求将触发新连接创建，带来明显延迟；同时高并发突增时，连接池需动态扩容，可能引发连接争抢或超时。
怎么设 minimum-idle 才合理
它不是拍脑袋定的数字，要兼顾三点：应用冷启动响应、常规并发压力、数据库资源承受力。
- 常规建议值是 最大连接数（maximum-pool-size）的 1/4 到 1/3。比如 max=20，minimum-idle 可设为 5～7
- 对低流量后台服务，可设为 2～3；对核心 API 服务，建议不低于 5
- 若数据库连接建立本身很慢（如跨公网、SSL 开启、权限校验复杂），initial 连接数略高些（如设为 8）能摊薄首请求延迟
- HikariCP 官方文档倾向“不显式设 minimum-idle”，让池子始终维持 maximum-pool-size 大小——但这只适合资源充足、连接成本极低的场景，生产环境慎用
配套必须调的参数
只调 minimum-idle 不够，还要同步确认以下参数协同工作：
-
maximum-pool-size：必须先算好上限。经验公式是
CPU核心数 × 2 + 有效磁盘数（如 4 核 + 1 SSD → 建议 9～10；再结合监控 QPS 和平均 SQL 耗时微调） - connection-timeout：建议 30000（30 秒），确保在连接不足时有足够等待窗口，而不是立刻失败
- idle-timeout：设为 30000（30 秒），避免空闲连接长期占着资源却不被回收
- max-lifetime：MySQL 建议 1800000（30 分钟），配合数据库端 wait_timeout 设置，防止连接被服务端静默断开
验证是否设得合适
上线后重点看两个指标：
- 应用刚启动后 1～2 分钟内，
HikariPool-1 - Before cleanup stats日志中显示的 active/idle 数量是否快速稳定在minimum-idle水平 - 高峰时段监控面板中，
Connections Acquired和Threads Awaiting Connection是否持续为 0；若有线程长时间等待，说明 initial + max 整体偏小
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
