Redis连接池max_connections需按Little’s Law计算：并发连接数≈QPS×平均响应时间，再叠加1.2～1.5倍余量，并受服务端max_connections硬限制约束，生产环境推荐30–100，需结合activeCount和waitCount监控调优。
Hyperf 3.1 的数据库或 Redis 连接池 max_connections 不能靠拍脑袋定，得结合业务实际并发压力和单次操作耗时来算——核心依据是 Little’s Law（利特尔法则）：并发连接数 ≈ QPS × 平均响应时间（秒）。这个值再叠加上安全余量和部署拓扑，才是你该设的 max_connections。
先算理论并发需求
比如你的接口当前峰值 QPS 是 800，平均 DB 查询耗时 120ms（0.12s），那理论上同时活跃的连接数就是：
800 × 0.12 = 96
这 96 是“正在被使用的连接”数量，不是池大小。连接池要能随时供应这些连接，所以 max_connections 至少得 ≥ 96。但还要考虑：
- 突发流量带来的瞬时尖峰（建议 ×1.2～1.5）
- 多个协程可能共用一个连接（Hyperf 默认协程安全，但若用了事务或长操作，连接会被独占更久）
- 其他组件（如 Redis、HTTP 客户端）也在争抢连接资源
再扣减数据库硬限制
Hyperf 再大也得听 MySQL 或 Redis 的。例如 MySQL 配置了 max_connections = 500，预留 50 给监控/DBA，剩下 450。如果你部署了 3 台 Hyperf 实例，那单台实例的连接池上限就不能超过：
(500 − 50) ÷ 3 ≈ 150
上面算出的 96 × 1.3 ≈ 125，没超 150，那就取 125～150 之间合理值（比如 130）。如果算出来是 200，就必须调低——否则应用一压就报“Too many connections”。
最后看部署与协程特性
Hyperf 是协程模型，一个 worker 进程可并发处理数百请求，但连接是共享资源。注意两点：
-
max_connections是整个进程内连接池的总上限，不是每协程一个 - 别盲目设高：池太大 → 空闲连接积压 → 占用 DB 内存（MySQL 每连接约 1–10MB）→ 触发 OOM 或主从延迟
生产环境常见稳妥范围：数据库池 20–80，Redis 池 30–100。起步可设 50，压测后按实际 activeCount 和 waitCount 监控微调。
附：快速验证是否合适
上线后盯两个指标：
- Hyperf 自带的
pool.connections.active（活跃连接数）是否长期接近max_connections - 日志里有没有 “Wait timeout” 或 “Connection wait time exceeded” 报错
有则说明池小了；如果 active 常年低于 max_connections 的 30%，且 idle 很高，说明设大了，浪费资源。
