Webman数据库连接池失效的主因是pool配置缺失或错误，需在connections['mysql']下显式声明；wait_timeout应设为大于P95耗时的值（建议≥3），max_connections须匹配MySQL线程上限与业务真实连接需求，idle_timeout建议设60防泄漏。
Webman 的数据库连接数超限，根本原因不是 max_connections 设低了，而是连接池参数没对齐实际并发和请求耗时——wait_timeout 太小会频繁抛异常，max_connections 太大会压垮 MySQL，idle_timeout 不设会导致空闲连接长期滞留。
database.php 里 pool 配置项必须显式声明
Webman 不会自动启用连接池，哪怕你用了 Swoole 或 Swow 驱动。如果 config/database.php 中的数据库配置里没写 'pool' 键，那就等于退化成每次请求新建连接，和传统 FPM 没区别。
-
'pool'必须作为'connections'['mysql']（或其他驱动）的子数组存在，不能丢在顶层 - 只支持
swoole或swow驱动；用pdo_mysql或mysqli时，pool配置完全被忽略 - 检查是否生效：启动服务后执行
php start.php status，看日志里有没有 “DB pool initialized” 类似提示
wait_timeout 设置不当直接导致 500 错误
wait_timeout 是从连接池取连接时的等待上限，单位秒。它不是 MySQL 的 wait_timeout，也不是 PHP 脚本超时。值设太小（比如 0.1），高并发下大量请求会在等连接时直接抛出 ConnectionPoolTimeoutException，返回 500。
- 线上建议从
3开始调，压测时观察错误率；低于1基本不可用 - 这个值要大于单次数据库操作的 P95 耗时，否则等于白配
- 不要和
mysql.connect_timeout混淆：后者是建连阶段的 TCP 超时，前者是池内排队超时
max_connections 和 idle_timeout 要配合业务节奏
max_connections 不是越大越好。它代表该连接池最多持多少个活跃连接，每个连接占 MySQL 一个线程。若设为 100，但你的 MySQL max_connections=150，其他服务或后台任务一挤，立刻报 “Too many connections”。
立即学习“PHP免费学习笔记（深入）”；
-
min_connections建议保持1，冷启动时避免首次请求卡顿 -
idle_timeout控制空闲连接存活时间，设60比设0更安全——连接空闲满 60 秒就回收，防止连接泄漏堆积 - 真实连接数 = 并发请求数 × 平均单请求 DB 操作次数 × 连接占用时长，拿这个估算比拍脑袋设
max_connections可靠得多
连接池不生效的三个隐蔽原因
即使配置全对，连接池也可能静默失效。最常踩的坑不在配置文件，而在运行时环境或代码调用方式。
- 用了
PDO::ATTR_PERSISTENT => true：Webman 连接池和 PDO 持久连接互斥，开了这个，池子直接绕过 - 手动 new PDO() 或 new mysqli()：任何绕过 Webman DB 封装的直连方式，都不走池子
- Worker 进程被意外 reload：比如改了
config/database.php后只执行php start.php reload，但连接池不会热更新，必须stop再start
连接池不是开个开关就完事的模块，它和你的并发模型、SQL 耗时分布、MySQL 线程资源是咬合在一起的。调参前先用 SHOW PROCESSLIST 看真实连接状态，比盲目改 max_connections 有用十倍。
