Db::pool() 是唯一启用连接池的入口，必须显式调用；未调用时即使配置有效也走传统短连接，导致连接数飙升。
Db::pool() 是唯一能真正启用连接池的入口，直接调用 Db::table() 或 Db::connect() 仍走传统短连接——这不是配置没生效，而是根本没走池子。
Db::pool() 必须显式调用，否则连接池形同虚设
ThinkPHP 的连接池不是全局拦截器，它不自动替换所有数据库操作。你得主动告诉框架：“这次我要用池子”。
-
Db::table('user')->select()→ 走传统连接，每次新建 PDO 实例 -
Db::pool()->table('user')->select()→ 走连接池，复用空闲连接 -
Db::pool()->transaction(function () { ... })→ 池化事务（默认Db::transaction()会绕过池子）
常见错误现象：配置了 db_pool 参数，但 show processlist 里连接数还是飙升，甚至报 PDOException: Too many connections。
原因基本就一个：代码里没改写法，还在用老接口。
注意：模型类（如 UserModel）默认也不走池子，除非你在模型里手动调用 Db::pool() 构造查询器，或重写 db() 方法返回池化实例。
config/swoole.php 中的 db_pool 配置才是有效位置
ThinkPHP 原生 config/database.php 里的任何 pool 相关字段（比如 pool_size、max_connections）完全无效——TP8 及更早版本不原生支持连接池，必须依赖 topthink/think-swoole 扩展。
立即学习“PHP免费学习笔记（深入）”；
正确做法：
- 确保已安装
swoole >= 4.8.0和topthink/think-swoole >= 3.1.0 - 在
config/swoole.php中配置：'db_pool' => [ 'max_idle' => 2, 'max_active' => 8, 'wait_timeout' => 2000, 'idle_timeout' => 60, ],
关键点：
-
max_active是硬上限，决定“最多创建几条连接”，不是并发数，而是连接总数 -
max_idle不是下限保护，而是空闲连接保有量；设为 0 表示空闲即回收，但无法防止突发时瞬间建满max_active -
wait_timeout是排队超时，不是连接超时；设太小（如 100ms）会导致大量PoolTimeoutException，设太大（如 5000ms）会让请求卡住拖垮接口
FPM 模式下该配置无效，只在 Swoole Worker 进程中生效。
deploy => 1 是 TP6 连接复用的隐藏开关，和连接池无关但常被混淆
TP6 的 deploy => 1 并不启用连接池，而是开启“连接复用基础结构”：它让同配置（同 host、port、db、user）的请求共享同一个 PDO 实例缓存，本质是单例 + 销毁控制优化。
- 它在 FPM 和 Swoole 下都生效
- 它不要求 Swoole，也不依赖
think-swoole - 它和
Db::pool()是两套机制，不能混用，也不能互相替代
典型误配：
- 在
database.php里写了'deploy' => 1，却没改代码调用Db::pool()→ 复用有限，高并发下仍可能打爆 MySQL - 在 Swoole 环境下只配
deploy => 1，没配db_pool→ 没有排队、限流、空闲回收等能力，只是比纯短连接稍好一点
真正需要连接池能力（比如限流、排队、跨协程复用），就必须走 think-swoole + Db::pool() 路线。
连接池实例绑定到 Swoole Worker 进程，不是全局共享
每个 Swoole Worker 进程拥有自己独立的连接池实例，彼此不通信、不共享连接。
这意味着：
- 你设
max_active => 8，启动 4 个 Worker，理论上最多可建立 32 条连接（8 × 4） - 如果某 Worker 承载了全部流量，它自己的池子会撑到 8 条；其他 Worker 的池子可能长期空闲
- 没有跨进程连接调度，所以 Worker 数量要结合实际 QPS 和平均连接耗时来调，不能盲目设高
容易被忽略的一点：Swoole 的 worker_num 和 MySQL 的 max_connections 要对齐。比如你设了 10 个 Worker，每个池子 max_active => 10，那 MySQL 至少得开到 100+ 连接，否则必然触发 Too many connections。
