hyperf连接池min_connections需匹配协程并发、启动负载与db响应能力，常规api建议4～8，swow环境必须≥1且≤max_connections的1/4～1/8，需结合wait_timeout设心跳避免老化。
Hyperf 连接池最小连接数（min_connections）不是“设得越小越省资源”，也不是“越大越稳”，而要匹配实际协程并发模型、服务启动阶段负载特征和数据库/Redis 的响应能力。设错容易导致冷启动卡顿、连接抖动或资源闲置。
根据服务启动与初始流量动态定值
Hyperf 在 Worker 启动时会预创建 min_connections 个连接，这部分连接不随请求波动变化，属于常驻资源。若设为 0，首次请求需等待连接建立（含 TCP 握手、认证、初始化），可能超时；若设过高（如 64），又会在低峰期白白占用数据库连接和内存。
- 常规 Web API 服务：建议从 4～8 起步，CPU 核数 ≤ 4 时取下限，≥ 8 时可适当上浮
- 定时任务或后台 Job 服务：若只在固定时段触发，可设为 1～2，避免空闲占用
- 混合型服务（如同时承载 HTTP + gRPC + 定时器）：按最高频协议的初始压力设，例如 HTTP 先起，就以 HTTP 的 min_connections 为准
Swow 环境下必须显式配置且不可沿用旧值
启用 Swow 后，Hyperf 不再识别原 Swoole 兼容层的 min_idle 或 min_connections（如旧版 databases.php 中写在 pool 外层的配置）。必须删除所有旧 pool 配置，在驱动同级新增 Swow 专用 'pool' => [...] 结构，并确保 min_connections 明确写出。
- Swow 要求
min_connections ≥ 1，设为 0 会导致连接池初始化失败 - 该值需 ≤
max_connections，且差值不宜过大（建议不超过 4 倍），否则 idle 回收策略易失衡 - Swow 的连接复用更激进，
min_connections = 8在多数中等规模服务中已足够覆盖冷启动+突发前几秒
结合数据库 wait_timeout 反向校验合理性
MySQL 默认 wait_timeout = 28800（8 小时），但生产环境常调为 300～1800 秒。如果 min_connections 设得高，而业务长期无请求，这些“常驻连接”可能被 MySQL 主动断开，但 Swow 池不会立即感知，下次取出时才报错。因此：
- 若 DB 的
wait_timeout设为 300 秒，建议将连接池的check_interval（心跳检测间隔）设为 ≥ 3000 毫秒，配合heartbeat => true - 此时
min_connections不宜超过 16——太多常驻连接在短超时下反而增加无效心跳开销 - 可通过
SHOW PROCESSLIST观察空闲连接存活时长，反推当前min_connections是否造成连接老化堆积
避免与 max_connections 倒挂或过度保守
常见误配是把 min_connections 设得极小（如 1），寄望“按需伸缩”，但 Swow 的扩容非瞬时：新连接需经历完整建连流程，高并发突袭时仍会排队等待。而 max_connections 若设得过大，又可能压垮 DB。
- 推荐比例：min : max ≈ 1 : 4 ～ 1 : 8（例如 min=8，max=32 或 64）
- 上线前用
ab或hey模拟 2× 平均 QPS，观察连接获取耗时是否稳定在 1ms 内；若出现明显毛刺，说明 min 偏低 - 监控
hyperf.pool.*.idle和hyperf.pool.*.active指标，若 idle 长期 ≈ min 且 active 波动剧烈，说明 min 设置合理；若 idle 长期为 0，说明 min 过小或 max 不足
