Hyperf 3.2 连接池配置需基于协程并发峰值（非QPS）、服务端资源上限及业务压力动态平衡：min_connections建议8～16防冷启动抖动，max_connections须≤服务端限制并按公式min(服务端总数÷Worker数, 协程峰值×0.4)计算。
Hyperf 3.2 的连接池（如 Redis、MySQL）中，min_connections 和 max_connections 不是拍脑袋定的数字，而是要结合协程并发量、服务端资源上限和实际业务压力来动态平衡。
看协程并发峰值，不是看 QPS
Hyperf 是协程模型，一个 Worker 进程能同时跑成百上千个协程。但每个协程在执行数据库或 Redis 操作时，会从连接池里取一个连接 —— 所以真正决定连接数需求的，是同一时刻正在做 I/O 的协程数量，而不是每秒请求数（QPS）。
- 比如你单 Worker 并发运行 200 个协程，其中约 30% 正在查 Redis，那瞬时连接需求 ≈ 60 个
- 若配置
max_connections => 32，就会频繁触发WaitTimeoutException - 建议先用压测工具（如 wrk + 协程密集型脚本）观察真实峰值连接占用
min_connections 要防冷启动抖动
min_connections 是连接池预热的“保底数”。它不等于最小使用量，而是指服务刚启动或低流量时，池里始终维持的空闲连接数。
- 设为 0：首次请求需现场建连，可能增加几十毫秒延迟（尤其 TLS/Redis AUTH 场景）
- 设太高（如 > max_connections 的 1/3）：空闲连接长期占着内存和服务端 fd，浪费资源
- Hyperf 3.2 实践中，8～16 是较稳妥的起始值，适用于中等规模服务（单 Worker 并发 ≤ 500）
max_connections 必须≤服务端限制
这个值不能只看 PHP 侧，必须和后端服务的实际承载能力对齐：
- Redis：默认
maxclients是 10000，但单机部署时建议留 20% 余量；集群模式下按分片数折算 - MySQL：受
max_connections和wait_timeout影响，还要考虑连接内存开销（每个连接约 2–3MB） - Swow 场景下注意：
check_interval ≥ 3000ms，否则心跳异常中断（Hyperf 3.2.4 已校验） - 推荐公式：
max_connections = min(服务端允许总数 ÷ Worker 数, 单 Worker 协程峰值 × 0.4)
上线前必做两件事
光配参数不够，得验证是否真生效：
- 用
swoole_get_local_socket_count()或ss -s | grep ESTAB查当前 ESTABLISHED 连接数，对比是否接近max_connections - 在关键服务方法里加日志，统计
$pool->get()的耗时分布，若大量请求卡在 2.0s（默认 wait_timeout），说明池子太小或连接泄漏
