Hyperf中无max_idle参数，只有max_idle_time控制单个连接空闲超时回收；min_connections仅预热连接数，连接复用取决于max_idle_time、MySQL wait_timeout及心跳协同。
Hyperf 3.0 默认使用 Swoole 协程 MySQL 客户端（co\MySQL 或基于 PDO 的协程封装），其连接池行为与传统线程池（如 HikariCP）不同：它不维护“空闲连接”概念，而是由协程调度器按需复用底层连接，因此 Hyperf 官方配置中并无 max_idle 参数——你看到的 max_connections 和 min_connections 是连接池的上下限，而所谓“idle”实际由 max_idle_time 控制单个连接空闲多久后被自动回收。
别混淆：Hyperf 没有 max_idle，只有 max_idle_time
在 Hyperf 的 MySQL 配置（config/autoload/db.php）中：
-
pool.max_connections：连接池最多可创建多少个连接（硬上限） -
pool.min_connections：服务启动时预创建的最小连接数（冷启动缓冲） -
pool.max_idle_time：连接空闲超过该秒数后被主动关闭（单位：秒，不是“数量”）
也就是说，“max_idle 连接数量”这个提法本身不符合 Hyperf 设计模型。它不统计或限制“当前有多少空闲连接”，只控制单个连接的生命周期。真正影响空闲连接数量的是 max_connections、并发压力、SQL 执行耗时及 max_idle_time 的协同效果。
合理设置 max_connections：按并发水位 + 耗时反推
推荐公式（适用于 OLTP 场景）：
max_connections ≈ QPS × P95 SQL 响应时间（秒）× 1.5～2.0
例如：
- 线上稳定 QPS = 120
- P95 查询耗时 = 80ms = 0.08s
- 理论最小连接需求 = 120 × 0.08 = 9.6
- 加缓冲后建议设为 15～20
⚠️ 同时必须满足：max_connections × 应用实例数 ≤ MySQL 的 max_connections × 0.7
比如 RDS 实例 max_connections = 3200，部署 4 台 Hyperf 服务 → 单机 max_connections ≤ 560，但实际远不需要这么大，20 就足够。
max_idle_time 怎么设才不掉连接？
这个值要略小于 MySQL 的 wait_timeout（默认 28800 秒 / 8 小时），但更重要的是适配中间链路：
- 若直连 MySQL，且
wait_timeout = 300（5 分钟），则max_idle_time建议设为 240～270 秒（4～4.5 分钟） - 若经过 RDS Proxy、Cloudflare Tunnel 或 NAT 网关，中间设备可能 60～120 秒就断连 → 此时
max_idle_time应设为 30～90 秒
Hyperf 会在连接空闲超时后自动 close，下次请求会新建连接，所以设太大会导致“僵尸连接”被复用报错；设太小则频繁重建，增加握手开销。
配套关键参数建议值（Hyperf 3.0 + MySQL 8.x）
以中等负载（QPS 100–300）为例：
-
pool.min_connections：5～10（避免冷启动抖动） -
pool.max_connections：15～30（按上述公式算，不盲目拉到 100+） -
pool.connect_timeout：5.0（秒，连接建立超时） -
pool.wait_timeout：3.0（秒，获取连接等待超时，防队列堆积） -
pool.max_idle_time：180～300（秒，根据wait_timeout和网络环境定） -
options.ATTR_TIMEOUT：3（PDO 执行超时，单位秒）
所有超时值保持梯度：connect_timeout ≥ wait_timeout > options.ATTR_TIMEOUT，避免逻辑混乱。
