min_connections无统一标准值，需据业务并发、DB承载力与资源成本设定，常见5～20；设0会导致首请求建连延迟，过小则冷启动易阻塞，应取低峰占用量1.2～1.5倍或并发协程数10%～15%，且min与max差值宜控制在3～5倍内。
Hyperf 连接池的最小连接数（min_connections）没有统一标准值，需根据业务并发特征、数据库承载能力和资源成本综合设定，常见范围是 5～20，中型服务通常设为 8～12。
为什么不能设为 0 或过小？
最小连接数代表连接池初始化后始终保活的空闲连接数量。设为 0 意味着每次首个请求都要新建连接，带来明显延迟；过小（如 1～2）则在突发流量初期容易触发连接创建阻塞，放大首屏响应时间。Hyperf 的协程连接池依赖“预热”来保障低延迟，保持少量常驻连接是协程友好型设计的基本前提。
怎么定一个合理值？
-
看日常最低活跃连接数：通过监控（如
hyperf:pool:stats命令或 Prometheus 指标hyperf_pool_active_connections）观察凌晨等低峰时段的稳定占用量，取其 1.2～1.5 倍作为下限参考 - 结合协程并发度：若服务平均并发协程数为 50，而单个数据库操作平均耗时 20ms，理论最小连接需求 ≈ 50 × 0.02 = 1 个（按排队论估算），但必须叠加安全冗余——一般建议不低于并发协程数的 10%～15%
-
避开数据库侧限制：确认 MySQL 的
wait_timeout（默认 8 小时）和max_connections，确保最小连接数 × 服务实例数远小于数据库总连接上限，防止连接打满
和最大连接数的关系要留意
最小与最大连接数差距不宜过大。例如设 min=5、max=200，虽能扛住峰值，但 95% 时间里 195 个连接闲置，既浪费内存又增加连接管理开销。推荐差值控制在 3～5 倍以内，比如 min=12、max=48，再配合动态伸缩（如用 Hyperf 的 PoolManager + 自定义扩容策略）更实用。
不复杂但容易忽略
