thinkphp 原生不支持数据库连接池，其db类和pdo底层仅实现请求级连接复用，无连接预分配、空闲回收等池化能力；所谓“连接池”实为swoole、proxysql等外部组件功能误归。
ThinkPHP 里根本没有数据库连接池
直接说结论：ThinkPHP 原生不支持数据库连接池，Db 类和 PDO 底层都是每次请求新建/复用单个连接，没有连接预分配、空闲回收、最大活跃数控制等池化能力。所谓“连接池”“自动扩缩容”，是把其他中间件（如 Swoole、ProxySQL、MySQL Router）的功能误归到了 ThinkPHP 头上。
常见错误现象：Too many connections 报错后去翻 database.php 配置，狂调 'max_active'、'min_idle' —— 这些配置项根本不存在于 ThinkPHP 官方配置中，是照搬 Druid 或 HikariCP 的写法，徒劳无功。
- ThinkPHP 的连接管理本质是「连接复用 + 请求生命周期绑定」：CLI 模式下可能复用，FPM 下基本每次请求 new PDO 一次
- 真正影响并发连接数的，是 PHP-FPM 的
pm.max_children和 MySQL 的max_connections，不是 ThinkPHP 配置 - 若用了 Swoole（如 think-swoole 扩展），才可能在协程内做连接复用，但那也不是传统意义的连接池，而是协程安全的
PDO实例缓存
想撑住突发流量，得从三层下手
ThinkPHP 本身不控连接生命周期，所以扩容阈值必须落在外围：Web 服务器层、PHP 运行时层、数据库层。各自关键点如下：
-
PHP-FPM 层：调高
pm.max_children是最直接手段，但需同步检查内存——每个子进程常驻约 20–40MB，设为 100 就可能吃掉 3GB 内存 -
Swoole 协程层（如启用 think-swoole）：通过
'pool' => ['max_idle_time' => 60, 'max_active' => 30]控制协程内连接复用上限，注意这个max_active是每个协程 worker 的本地限制，不是全局池大小 -
MySQL 层：必须调大
max_connections，同时检查wait_timeout和interactive_timeout，避免短连接频繁创建销毁；对读多写少场景，可前置Redis缓存，降低 DB 实际压力
think-swoole 的 pool 配置容易被当“连接池”滥用
很多人看到 think-swoole 文档里有 pool 配置，就以为启用了连接池。其实它只是协程安全的连接缓存容器，行为和普通 PDO 复用没本质区别，只是线程/协程隔离做得更好。
典型错误用法：'max_active' => 1000 —— 这会导致每个 worker 进程最多持 1000 个空闲连接，若开 4 个 worker，瞬间占满 MySQL 的 max_connections，反而引发雪崩。
- 推荐值：生产环境
max_active不超过 20，max_idle_time设为 30–60 秒，让空闲连接及时释放 - 必须配合 MySQL 的
wait_timeout（建议设为 60）保持一致，否则会出现MySQL server has gone away - 开启
debug模式时，可在日志里看到[swoole] db pool: used=3, idle=7, total=10这类统计，这才是真实水位
真正的连接池要靠外部组件，ThinkPHP 只负责适配
如果业务确实需要连接池（比如高并发短事务、微服务间频繁调用），ThinkPHP 不能自己实现，只能对接外部方案：
-
ProxySQL：部署在应用和 MySQL 中间，支持连接复用、读写分离、熔断限流；ThinkPHP 只需把数据库地址指向 ProxySQL 的
6033端口，其余无感 -
Swoole MySQL 协程客户端：绕过 PDO，用
Swoole\Coroutine\MySQL直连，再配合Channel自建简易池；但需自行处理重连、超时、事务一致性，复杂度陡增 -
不建议用 PDO-Pool 类库：社区有几个基于
Channel封装的 PDO 池，但无法保证事务上下文隔离，在 ThinkPHP 的模型链式调用中极易出错
最常被忽略的一点：连接池带来的延迟掩盖了 SQL 本身的慢查询问题。上线前务必用 slow_query_log 和 EXPLAIN 确认单条查询是否已优化到 50ms 内——池再大，也救不了一条 2s 的 SELECT *。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
