判断连接池配置是否合理需协同分析连接数与错误率：峰值>max_connections的85%说明池过小易超时；错误率上升但hyperf_db_query_duration_ms稳定，则问题在排队或连接健康；配合DB锁、慢查询指标及轻量压测可精准定位失衡点。
要判断连接池配置是否合理，不能只看连接数或错误率单个指标，得把两者放在一起看——连接数是“供给”，错误率是“结果”，它们的组合能直接暴露配置失衡点。
看连接数峰值是否持续逼近上限
在 Prometheus 中查 hyperf_db_pool_used_connections 指标，观察它的 95 分位值和最大值：
- 如果峰值长期 > max_connections 的 85%，说明池子太小，协程排队变多，容易触发 wait timeout 错误
- 如果峰值常年
- PostgreSQL 场景下，再同步查 SELECT count(*) FROM pg_stat_activity，若 DB 侧连接数远高于应用上报的 used_connections，说明有连接泄漏（比如 pipeline 未 exec、事务没 commit）
把错误类型对应到连接池行为
不同错误指向不同连接池环节：
-
"WaitTimeoutException" → 连接池已满，新协程等不到空闲连接。优先调大
max_connections或压降单次查询耗时 -
"MySQL server has gone away" → 连接被服务端主动断开，但池子没及时剔除。检查
heartbeat => true和max_idle_time是否严格小于 DB 的wait_timeout -
"Too many clients"（PostgreSQL）或 "Too many connections"（MySQL）→ 应用连接数超过 DB 限制。此时要同步看 DB 的
max_connections和应用池的max_connections，建议后者 ≤ 前者 × 0.7
结合慢查询与锁指标交叉验证
高错误率未必是连接池的问题，也可能是数据库内部卡住导致连接被长时间占用：
- 查 mysql_global_status_innodb_row_lock_time_avg：平均行锁等待时间飙升，说明业务有热点行争抢，连接被堵在锁上，池子再大也没用
- 查 mysql_global_status_slow_queries：慢查询增多会拉长单连接占用时间，间接推高连接池使用率
- Hyperf 的 hyperf_db_query_duration_ms 只反映 PDO 执行耗时，不含排队时间。若它稳定但错误率上升，问题大概率在排队或连接健康环节
做一次轻量压力测试快速定位
不依赖线上流量，用 ab 或 wrk 对一个简单 DB 查询接口施加可控并发：
- 固定 QPS（比如 100），逐步增加连接池
max_connections，观察错误率是否明显下降。若从 20 调到 40 错误率骤降，说明原配置偏小 - 固定
max_connections，缩短wait_timeout（如从 5.0 改为 2.0），若错误率上升但 DB 连接数没变化，说明是排队策略太激进，该放宽等待容忍度 - 开启
heartbeat后重测，若 "gone away" 类错误归零，就验证了连接复用前的健康检查缺失是主因
