报Connection timeout或wait_timeout错误，大概率因wait_timeout设太小且max_connections未匹配并发压力；前者控制协程等待空闲连接最长时间，生产建议设5.0秒，开发不低于2.5秒；后者需结合DB最大连接数与QPS合理配置，如单机MySQL默认151，则Hyperf连接池建议≤80。
报 Connection timeout 或 wait timeout 错误，大概率是 wait_timeout 设太小，而 max_connections 没跟上并发压力。
为什么 wait_timeout 小于 3.0 秒就容易出问题
这个值控制协程在连接池里“等空闲连接”的最长时间。设成 1.0 或 2.0，高并发下稍有抖动（比如某条 SQL 执行慢了 200ms），后续请求就会排队超时，直接抛出 wait timeout 日志或 Pool exhausted 异常。
-
wait_timeout不是数据库层面的wait_timeout，它是 Hyperf 连接池自己的等待策略参数 - 它和
max_connections是联动关系：池子越小，每个请求越容易卡在等待队列里 - 生产环境建议统一设为
5.0，开发/测试可设3.0，但不要低于2.5
max_connections 设多少才够用
默认 10 在压测或中等流量服务里基本不够用。它不是越大越好，要结合 DB 实例最大连接数、单机 QPS 和平均响应时间估算。
- MySQL 默认
max_connections = 151，Hyperf 服务若只连一个库，max_connections建议不超过80 - 如果服务部署多实例，按单机 4–8 个 Worker 计算，每个 Worker 平均并发 10–15 请求，池子至少要
50起步 - Redis 连接池也要单独配，不能复用 MySQL 的
max_connections值，否则会抢资源 - 配置示例：
'max_connections' => (int) env('DB_POOL_MAX', 80)，配合.env动态管理
wait_timeout 和 max_connections 配错的典型现象
这两个参数配歪后，错误表现往往很“像”，但根因不同，得靠日志和监控区分：
- 只调大
max_connections但wait_timeout还是2.0→ 大量wait timeout报错，SHOW PROCESSLIST看不到堆积连接 - 只调大
wait_timeout但max_connections还是10→ 请求延迟毛刺明显，MySQL 出现Too many connections，hyperf:monitor可见连接池长期busy > 90% - 两个都设太高（如
max_connections=200,wait_timeout=10.0）→ 数据库连接耗尽，其他服务连不上，且协程等待过久导致超时级联
真正难调的是平衡点：max_connections 要留余量防突发，wait_timeout 要短到能快速失败不拖垮下游，又不能短到误杀正常排队。上线前务必用 ab 或 hey 模拟真实请求节奏压测，别只看单接口 RT。
