hyperf连接池连接数需“够用但不冗余”，须从三层面验证：1. 结合协程并发量看连接使用率；2. 对齐数据库服务端限制并留余量；3. 压测找吞吐与延迟拐点；swow环境下还需校准心跳与回收参数。
Hyperf 中连接池连接数不是设得越多越好，它和系统负载（CPU、内存、协程数、数据库服务能力）存在强耦合关系。盲目调大 max_connections，反而会加剧数据库压力、触发连接拒绝或引发 EMFILE 错误；设得太小，又会导致请求排队、超时、QPS 下降。关键是要让连接数“够用但不冗余”，需从三个层面交叉验证。
看连接池实时指标与协程并发量的比值
Hyperf 的 hyperf_db_pool_used_connections 和 hyperf_db_pool_idle_connections 指标，要结合当前活跃协程数（hyperf_server_active_coroutine_count）一起看：
- 若
used_connections / active_coroutines > 0.8，说明大部分协程都在争抢连接，池子偏小，需适当提高max_connections - 若
idle_connections > min_connections * 1.5且持续 5 分钟以上，说明连接长期闲置，可考虑下调min_connections或缩短max_idle_time - 注意：单个协程通常只持有一个连接，但事务嵌套、多库操作、异步回调等场景可能临时占用多个连接
对齐数据库服务端限制与连接池上限
连接池最大值必须低于数据库侧硬限制，并保留安全余量：
- MySQL：检查
show variables like 'max_connections';，Hyperf 连接池max_connections建议 ≤ DB 限制的 70%（例如 DB 是 200，则池子设 140） - PostgreSQL：查
SHOW max_connections;，同时确认superuser_reserved_connections已预留，Hyperf 池值建议 ≤ (max_connections − reserved) × 0.8 - Redis：观察
redis-cli info | grep connected_clients，Hyperf 的max_connections应 ≤ Redis 配置的maxclients减去监控、备份等其他客户端占用
压测中观察连接数与吞吐/延迟的拐点
用 wrk 或 hey 对接口施加阶梯式负载（如 100 → 500 → 1000 RPS），同步采集三组数据：
- 连接池使用率（
used / max）、平均等待时间（hyperf_db_pool_wait_duration_ms） - 数据库线程数（
threads_connected）、InnoDB 行锁平均等待（innodb_row_lock_time_avg） - 接口 P95 延迟、错误率（尤其是
wait timeout和Too many clients） - 拐点通常出现在：连接池使用率突破 90% + P95 延迟陡增 3 倍 + 行锁等待明显上升 —— 此时的连接池值就是当前负载下的合理上限
Swow 环境下需额外校准心跳与回收节奏
启用 Swow 后，连接生命周期管理逻辑变更，旧参数易失效：
-
check_interval必须 ≥ 3000ms（3 秒），否则心跳异常中断，空闲连接无法及时释放 -
max_idle_time应略大于业务最长 SQL 执行耗时（如最慢查询 800ms，则设为 1200ms），避免连接被误杀 - Swow 不兼容 Swoole 的 pool 配置结构，必须删除原
pool一级配置，改用'pool' => ['min_connections' => 8, 'max_connections' => 64, ...]格式
