Hyperf连接池max_connections无统一标准值，须依服务类型（MySQL/Redis等）、协程并发峰值、服务端资源上限及部署规模动态设定：MySQL推荐30–100（Swow模式16–64），Redis推荐30–100，均需结合Little’s Law计算并压测验证。
Hyperf连接池的max_connections不能统一设一个“标准值”，得看你是连 MySQL、Redis 还是其他服务，更关键的是要结合你自己的协程并发峰值、服务端资源上限和部署规模来定。盲目照搬别人配置，轻则浪费内存，重则触发连接拒绝或服务卡顿。
先看 MySQL 连接池怎么设
MySQL 侧有硬限制（max_connections），比如默认 151，生产环境通常设为 500～2000；但你要留出空间给 DBA、监控工具和主从同步线程，实际能分给 Hyperf 单实例的往往只剩 60%～80%。
- 单台 Hyperf 实例的
max_connections≤ （MySQL 总可用连接数 ÷ Hyperf 实例数） - 同时还要满足：≤ 单 Worker 协程峰值 × 0.4（Hyperf 3.2 推荐公式，防连接争抢）
- Swow 模式下建议范围是 16～64，且必须配
check_interval ≥ 3000，否则心跳异常断连 - 常见稳妥值：中等业务选 30～60；高并发读写+多 Worker 场景可到 80～100，但需压测验证
再看 Redis 连接池怎么设
Redis 默认 maxclients 是 10000，看似很宽裕，但单机部署时建议只用 70%～80%，集群则按分片数折算。更重要的是——Redis 连接非常轻量，但并发高时容易因连接复用不及时导致 WaitTimeoutException。
- 按 Little’s Law 粗算：≈ QPS × 平均响应时间（秒） × 1.3～1.5（余量）
- 例如 QPS=1000、平均耗时 8ms → 1000 × 0.008 = 8，再 ×1.4 ≈ 11 → 实际设 30～50 更稳
- 生产环境 Redis 池推荐 30～100；起步可设 50，上线后盯
activeCount和waitCount监控调优 - Swow 下必须用
hyperf/redis ≥ 3.2.5+SwowHandler，否则连接无法复用
min_connections 别设为 0，也别太高
min_connections 是冷启动时池里始终保有的空闲连接数，不是“最低使用量”。它影响首请求延迟和资源占用平衡：
- 设为 0：首次请求要现场建连，TLS 握手+AUTH 可能多拖 20～50ms
- 设太高（如 >
max_connections的 1/3）：空闲连接长期占着内存和服务端 fd，尤其 MySQL 每连接约 2～3MB - Hyperf 3.2 实践中，8～16 是较通用的起始值，适配单 Worker 并发 ≤ 500 的中型服务
上线前必须验证是否真生效
光改配置没用，得看运行时真实表现：
- 查系统级连接数：
ss -s | grep ESTAB或swoole_get_local_socket_count()，确认 ESTABLISHED 数接近你设的max_connections - 加日志统计
$pool->get()耗时：若大量请求卡在 2.0s（默认wait_timeout），说明池子小了，或存在连接泄漏 - 暴露
getCurrentConnections()/getConnectionsInChannel()到 Prometheus，长期观察使用率波动
