Webman的数据库连接池不是跨进程中心化池，而是每个Worker进程独立维护连接池，16个Worker配max_connections=20时实际最多320连接；其本质是进程级复用+协程调度+DB侧兜底。
Webman 本身不提供跨进程的中心化数据库连接池，所谓“承载千万级流量”的连接池，本质是每个 Worker 进程独立维护一组复用连接 + 合理的协程调度 + 数据库侧资源兜底。直接照搬传统 Java 连接池配置会失效。
为什么 Webman 的连接池不是“一个池子管所有进程”
Webman 基于 Workerman（或 Swoole/Swow 协程驱动），Worker 进程常驻内存，但进程间内存隔离。你在 config/database.php 中配的 'pool' 参数，只对当前进程生效；每个 Worker 启动时会初始化自己的连接池实例，彼此不共享。
这意味着：若你启了 16 个 Worker，max_connections 设为 20，理论最大连接数就是 16 × 20 = 320 —— 不是 20。千万级 QPS 下，真正瓶颈往往不在 PHP 层连接数，而在 MySQL 的 max_connections、网络带宽、慢查询或锁竞争。
- 协程未开启时，每个 Worker 内部串行执行，
min_connections设为 1 就够用，max_connections实际不会被撑开 - 协程开启后（如使用 Swow 或 Swoole 5+），单 Worker 内可并发执行多个请求，此时
max_connections才真正起作用 -
wait_timeout超时抛出的是ConnectionPoolTimeoutException，不是 MySQL 的Lost connection，二者要区分处理
database.php 中必须调优的 4 个 pool 参数
仅当使用 Swoole 或 Swow 驱动时，pool 配置才生效（Workerman 原生不支持协程，其“连接池”实为单连接复用）。关键参数需按压测反馈调整，而非套用经验值：
-
max_connections：建议从 10 开始压测，逐步加到 30–50。超过 50 后性能增益极小，反而加剧 MySQL 线程上下文切换 -
min_connections：设为 1 即可。设为 0 可能导致首请求延迟略高（需懒创建），但节省空闲资源 -
idle_timeout：必须 ≤ MySQL 的wait_timeout（默认 28800 秒）。推荐设为 50–300 秒，避免连接被服务端主动断开后还留在池中 -
heartbeat_interval：必须 SELECT 1，太频繁增加无谓负载，太长则失效连接清理滞后
千万级流量下真正卡脖子的不是连接数，而是这三件事
你把 max_connections 调到 100，MySQL 却卡在 innodb_row_lock_time_avg 高达 200ms，那连接池再大也白搭。实际线上要盯住：
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- MySQL 侧是否开了
skip-name-resolve？DNS 反查会把连接卡在Connecting状态，尤其在容器/K8s 环境 - 所有写操作是否都走事务？没显式
begin的语句会触发隐式事务，延长锁持有时间 - 连接池返回的连接是否被正确释放？Webman 的
Db::connection()默认自动释放，但手动调用->getConnection()后忘了->release()，就会泄露
协程环境下 Redis 和 DB 连接池必须错开配置
Redis 和 MySQL 共用同一组 Worker 进程，但它们的连接池行为完全不同：Redis 的 max_connections 是每进程上限，而 MySQL 的连接更重、更易受网络抖动影响。常见误配是两者都设成 20，结果 Redis 池占满，MySQL 请求排队等超时。
推荐比例（单 Worker）：redis.pool.max_connections : mysql.pool.max_connections ≈ 3 : 1。例如 Redis 设 30，MySQL 设 10 —— 因为 Redis 操作快、复用率高，MySQL 则更需留足余量防慢查询拖垮整个池。
另外，redis.php 和 database.php 中的 idle_timeout 必须不同（比如 Redis 设 50，MySQL 设 200），否则心跳检测可能因时间同步问题集体失效。
连接池不是魔法开关，它只是把“连接管理成本”从每次请求下沉到进程启动阶段。真正决定能不能扛住千万级流量的，是你有没有在业务层规避长事务、有没有用好索引、有没有把非核心 DB 调用降级或异步化——池子再大，也救不了一个 SELECT * FROM user ORDER BY created_at DESC LIMIT 1000000, 20。
