min_connections 不该设为 0，生产环境应设为 2～5；设为 0 会导致冷启动首请求失败、协程上下文污染及 p99 延迟升高，且需与 max_connections 按 1:10～1:25 比例联动配置，并通过 hyperf:pool-status 等工具验证 idle 连接是否稳定维持。
Hyperf 的 MySQL 连接池 min_connections 不该设为 0，生产环境建议固定为 2～5，冷启动抖动和协程上下文污染比“省资源”更致命。
为什么 min_connections 设 0 在 Hyperf 里是高危操作
Hyperf 启动后若 min_connections = 0，连接池初始为空；首个请求进来时需同步建连，而 Swoole 协程 Hook 尚未完全就绪，容易触发 Connection refused 或 connect_timeout 超时（尤其在 Docker 网络或云数据库 DNS 解析慢的场景）。这不是连接池“懒加载”的优势，而是协程调度与连接初始化时机错位导致的首请求失败。
更隐蔽的问题是：协程上下文污染。当多个协程并发触发首次建连，可能因共享 Context 或 DNS 缓存未隔离，导致后续连接复用异常（比如 MySQL server has gone away 错误集中爆发）。
- 设 0 时，
swoole_get_local_socket_count()初始返回 0，但第一个 DB 请求会阻塞整个协程调度器约 100–300ms - 设 ≥2 后，服务启动即预热连接，
hyperf:pool-status可见idle> 0，首请求直接复用 - 阿里云 PolarDB、腾讯云 TDSQL 等云数据库对首次握手延迟敏感，
min_connections=0显著抬高 P99 延迟
min_connections 和 max_connections 必须联动，不能孤立调
很多人单独调大 min_connections 却忽略它和 max_connections 的比例关系。Hyperf 连接池不是静态容器，而是一个带弹性伸缩的协程资源池——min_connections 是下限，max_connections 是硬顶，中间靠 max_idle_time 和 idle_timeout 控制收缩节奏。
- 若
min_connections = 10但max_connections = 20，低峰期仍维持 10 个空闲连接，浪费内存且增加 MySQLThreads_connected压力 - 若
min_connections = 2、max_connections = 200，则既能应对突发流量，又避免常驻连接过多；推荐比例为 1:10～1:25 - 云数据库实例规格越小（如 2 核 4GB），
min_connections应越保守（建议 2），防止连接数过早触达 DB 侧max_connections限制
怎么验证 min_connections 设得是否合理
不看文档，看运行时指标。Hyperf 提供了原生命令和底层 API 直接观测连接池真实状态，比日志更准、比监控更及时。
- 执行
php bin/hyperf.php hyperf:pool-status，检查输出中idle是否稳定 ≥min_connections值（注意：刚启动后需等 3–5 秒才收敛） - 在
app/Service/PoolMonitorService.php中调用$pool->getConnectionsInChannel()，每 10 秒打点记录，观察低峰期idle是否持续低于设定值（说明被意外回收） - 压测时用
ss -s | grep ESTAB对比ESTABLISHED数与hyperf:pool-status的current，若前者远大于后者，说明连接泄漏，min_connections再高也无意义
真正难的不是设多少，而是确认这个“最小数”有没有被真正维持住——Hyperf 的连接池收缩逻辑藏在 IdleConnectionChecker 线程里，它只认 max_idle_time 和 idle_timeout，min_connections 本身不阻止收缩。所以配完必须验证 idle 连接是否真“活”着。
