Hyperf中Swow环境下必须显式配置max_connections等专用参数，删除旧pool块并新增Swow专用pool数组，各数据库实例需独立设值，且须综合CPU、内存、数据库max_clients及ulimit-n平衡设定。
Hyperf 中数据库连接池的最大连接数（max_connections）需根据实际部署环境和数据库服务能力显式配置，不能依赖默认值或自动推算。尤其在启用 Swow 协程引擎后，旧版 Swoole 兼容配置会失效，必须使用 Swow 专用参数结构。
Swow 环境下必须重配 max_connections
Hyperf 3.1+ 启用 Swow 后，原 config/autoload/databases.php 中的 pool 配置会被忽略。必须删除旧 pool 块，在 MySQL 或 PostgreSQL 连接配置同级新增 Swow 专用 pool 数组：
-
'max_connections' => 64：明确设为整数值，建议不超过目标数据库实例的max_connections设置的 70% -
'min_connections' => 8：保持常驻连接数，避免冷启动延迟 - 必须同时设置
'check_interval' => 3000（≥3000 毫秒），否则心跳检测异常导致连接泄漏 - 修改后需执行
rm -rf runtime/container && php bin/hyperf.php start，否则旧 Pool 实例残留，新配置不生效
多版本/多实例数据库要独立设 max_connections
不同数据库版本或部署形态（如 MySQL 5.7 RDS、MySQL 8.0 自建、PostgreSQL 14）协议与资源限制不同，不能共用连接池，更不能共用 max_connections 值：
- 为每个实例定义独立连接名，例如
mysql_v57_rds、mysql_v80_local - 每个连接块内完整声明
driver、host、pool，且pool中的max_connections按该实例实际承载力单独设定 - 例如 MySQL 5.7 RDS 实例
max_connections = 200，其连接池max_connections建议 ≤150；而 MySQL 8.0 本地实例若max_connections = 1000，可设为 512
动态计算安全上限的参考依据
max_connections 不是越大越好，需综合以下四点平衡：
- CPU 核数：Swow 协程调度能力较强，单 Worker 可支撑较多连接，但每连接仍占一定调度开销
- 内存容量：每个 MySQL 连接约占用 2–4 MB 内存（含 buffer、sort、join 等），64 连接 ≈ 256 MB
-
数据库 max_clients：必须低于服务端
max_connections，留出管理、监控等预留连接 - 系统 ulimit -n：总连接数（DB + Redis + gRPC 等）不能超过文件描述符上限，建议设为 65535 或更高
非 Swow 环境（Swoole Base 模式）的兼容写法
若暂未升级 Swow，仍用 Swoole 模式，可在 databases.php 的连接配置中保留传统 pool 结构：
-
'max_connections' => 32（注意：此处是 Swoole 兼容层识别的字段） - 同时需确保
'wait_timeout'和'max_idle_time'合理，避免 idle 连接堆积 - 该配置在 Swow 下会被跳过，仅在
'mode' => SWOOLE_BASE时生效
