ThinkPHP原生无连接池，必须通过think-swoole的DbPool实现；需Swoole环境，配置db_pool并显式调用Db::pool()，注意避免传统连接入口绕过池子，合理设置max_active等参数防连接超限。
ThinkPHP 连接池本身不存在，think-swoole 的 DbPool 是唯一可行路径
ThinkPHP 原生不支持数据库连接池 —— 它的 Db 类每次调用都走 PDO 新建连接（或复用 PDO::ATTR_PERSISTENT），没有连接生命周期管理、没有队列等待、没有最大空闲/活跃数控制。所谓“连接池”必须依赖 Swoole 扩展 + think-swoole 提供的 DbPool 组件，且仅适用于 Swoole HTTP/Task/Worker 模式，传统 FPM 下完全无效。
实操建议：
- 确认已安装
swoole（>= v4.8.0）和topthink/think-swoole（>= v3.1.0） - 仅在
config/swoole.php中配置db_pool，FPM 的database.php配置对连接池无影响 -
DbPool默认不启用，需显式调用Db::pool()获取连接，直接用Db::table()仍走传统连接 - 连接池实例绑定到 Swoole Worker 进程，非全局共享；不同 Worker 有各自独立池子
如何配置 max_idle 和 max_active 控制创建速率
连接创建速率由池子“按需扩容”逻辑决定：当请求到来时，若空闲连接不足，会新建连接直到达到 max_active；空闲连接超时（idle_timeout）后被回收，但不会主动销毁低于 max_idle 的连接。真正限制“突发创建”的是 max_active —— 它是硬上限，超出的请求会在池子内排队等待（默认最多等 3 秒，超时抛出 PoolTimeoutException）。
关键参数说明：
立即学习“PHP免费学习笔记（深入）”；
-
max_idle：保留在池中不销毁的最小空闲连接数，设为 0 表示空闲即回收，但无法抑制创建高峰 -
max_active：同一时刻最多存在的连接总数，设为 10 就意味着哪怕并发 100，也最多只创建 10 条连接，其余 90 个请求排队或失败 -
wait_timeout：排队等待连接的最大毫秒数，设太小（如 100）会导致大量WaitTimeoutException，设太大（如 5000）可能拖垮接口响应 -
idle_timeout：空闲连接存活时间（秒），与创建速率无关，只影响资源释放节奏
示例配置（config/swoole.php）：
'db_pool' => [
'max_idle' => 2,
'max_active' => 8,
'wait_timeout' => 2000,
'idle_timeout' => 60,
],
为什么 Db::pool()->table() 有时还是报 PDOException: Too many connections
这不是连接池失效，而是你没关掉传统连接入口。ThinkPHP 在模型、查询构造器、事务等场景下，仍可能绕过 DbPool 直接调用原生 Db::connect()，尤其以下情况高发：
- 使用
Db::transaction()—— 默认走非池化连接，必须改用Db::pool()->transaction() - 模型类（
app\model\User）里调用self::where()—— 默认不走池，需显式指定连接：self::connect('pool')->where(...) - 手动 new PDO 或调用
Db::raw()执行原生 SQL —— 完全脱离池控制 - 多个
Db::pool()实例混用（比如不同数据库配置），但共用同一 Swoole Worker，导致总连接数叠加超限
验证方式：在 DbPool 的 createConnection 方法里加日志，看是否真被调用；同时用 show processlist 观察 MySQL 实际连接来源 IP 和命令。
连接池 + 限速后，为什么 QPS 上不去甚至更慢？
连接池不是银弹。它把“连接创建开销”转移到了“排队等待”上。当 max_active 设得太低，或 wait_timeout 太短，大量请求在池子门口卡住，反而放大延迟。真实瓶颈常在别处：
- MySQL 自身
max_connections没同步调大，Swoole 多 Worker × 每个池max_active可能远超 MySQL 承受值 - 慢查询未优化，单条 SQL 耗时 800ms，8 个连接全堵死，后续请求全排队，QPS 必然断崖下跌
- 业务代码里存在同步阻塞操作（如 curl、file_get_contents、sleep），占着连接不放，池子被“饿死”
-
DbPool的连接复用基于协程，若你在协程外（如 Swoole Timer 回调）误用Db::pool()，会触发非协程安全操作，引发崩溃或连接泄漏
最易被忽略的一点：DbPool 不自动处理连接健康检测。如果 MySQL 主动断连（如 wait_timeout 触发），池子里的“脏连接”不会被及时剔除，后续请求拿到就报错 —— 必须配合 validation_query（如 SELECT 1）和 test_on_borrow 才能规避。
