Hyperf数据库连接池调优需动态匹配业务QPS、DB承载力与协程节奏：max_connections建议从峰值QPS×1.5起步（如QPS 800→1200），生产常见50～200；min_connections设为max的10%～30%以避免冷启动延迟；wait_timeout设2.0～3.0秒、max_idle_time设30～60秒，均须小于DB侧超时阈值；启用heartbeat（30～60秒）防失效连接。
Hyperf数据库连接池调优不是套用固定数值，而是根据业务并发特征、数据库承载能力和协程调度节奏动态匹配。关键在避免“连接不够用”和“连接空耗资源”两个极端。
看业务峰值QPS和单请求DB操作数
先估算每秒需要多少个活跃连接：比如平均每个请求执行3次查询，峰值QPS为2000，那理论最小活跃连接需求是 2000 × 3 = 6000。但实际不用配这么高——因为协程是复用连接的，一个连接可被多个协程轮转使用。
更实用的起点是：从 max_connections = 峰值QPS × 1.5 开始试探（例如QPS 800 → 先设1200），再结合监控逐步下调。生产环境常见配置区间是50～200，超200需确认数据库侧是否允许（如MySQL默认 max_connections=151）。
min_connections别设为1，尤其在高并发服务启动时
默认 min_connections=1 容易导致服务刚启动就遭遇大量请求时，连接池来不及预热，协程排队等连接，引发首波延迟毛刺。
建议设为 max_connections 的 10%～30%（如 max=100，则 min=10～30），让服务启动即持有一定数量已建连的连接，平滑承接初始流量。
- 设太低：冷启动慢，初期 wait_timeout 超时风险上升
- 设太高：空闲连接长期占用数据库连接数，浪费资源
wait_timeout 和 max_idle_time 要配合数据库侧 timeout
wait_timeout 是协程向连接池“要连接”时最多等多久；max_idle_time 是连接空闲多久后自动回收。这两个值必须小于数据库自身的 wait_timeout（MySQL 默认 28800 秒）和 idle_in_transaction_session_timeout（PostgreSQL 推荐设为 60～300 秒）。
典型安全组合：
- wait_timeout: 2.0～3.0 秒 —— 协程等太久说明连接池已饱和，应快速失败或降级
- max_idle_time: 30～60 秒 —— 高于应用层心跳间隔，低于DB侧空闲断连阈值
若发现连接池频繁新建/销毁连接（日志中出现大量 “create connection”），大概率是 max_idle_time 设得太短。
heartbeat 心跳检测要开，但别太勤
heartbeat=-1 表示禁用心跳，适合内网稳定环境；但线上建议开启，防止因网络闪断、DB重启等导致连接池保留失效连接。
推荐设为 30～60 秒，频率低于 max_idle_time 即可（例如 max_idle_time=60，heartbeat=45）。太频繁会增加无谓IO压力，太长则失效连接滞留时间过久。
注意：PostgreSQL 连接需额外在 commands 中加 SET TIME ZONE 'UTC' 类初始化语句，确保复用连接时状态一致。
