所需连接数≈qps×平均响应时间，如50 qps、200ms耗时需10连接，实际应设30～50并加安全余量；需监控线程连接数、超时日志及tcp连接数，排查假性占用，并在swow环境下按其规则重配参数。
连接池连接数和请求量之间不是简单的一一对应关系，而是受并发度、单次耗时、连接复用率共同影响的动态平衡。关键不在于“有多少请求”，而在于“同一时刻最多有几个请求在用连接”。
看懂核心公式：所需连接数 ≈ QPS × 平均响应时间
比如接口平均 200ms 返回，QPS 是 50，理论需要约 10 个连接（50 × 0.2 = 10）。但这是理想值，实际要加安全余量：
- 留出 2–3 倍缓冲：设 max_connections = 30～50 更稳妥
- 突发流量会拉高瞬时连接需求，不能只按平均值配
- 事务、pipeline、长轮询等场景会让单连接占用时间远超平均值
用运行时指标验证是否匹配
光算理论值不够，得看真实水位：
- 查 pool.max_connections 和 mysql_global_status_threads_connected（通过 mysqld_exporter）对比：若后者长期接近前者，说明池子快满了
- 观察 WaitTimeoutException 日志频率：频繁出现=连接池供不应求
- 用 swoole_get_local_socket_count() 或 ss -s | grep ESTAB 看当前 TCP 连接数，确认是否贴着 ulimit 上限
注意连接“假性占用”带来的误判
有些连接明明没在干活，却一直被占着，导致你以为连接数不够，其实是泄漏：
-
Redis pipeline/multi 忘记
exec()或异常跳出，连接不会自动释放 - MySQL 事务未提交或回滚，连接持续持有锁并占用连接槽位
- 协程长时间阻塞（如 sleep、等待外部 API），连接无法归还池中
Swow 环境下需单独校准
Hyperf 切 Swow 后，旧配置失效，必须重设参数：
- 删掉原
pool配置块，改用 Swow 专用结构 - min_connections 建议设为 CPU 核数 × 2，max_connections 按 QPS × 耗时 × 3 计算后向上取整
- Swow 要求 check_interval ≥ 3000ms，否则心跳异常中断连接
