ThinkPHP不同版本如何影响数据库连接池性能与高效配置？

本文共计911个文字，预计阅读时间需要4分钟。

官方底层使用的可能是 PDO 或 MySQLi，每次请求都是短连接——即查询完毕后立即关闭连接，不会重复使用连接。所谓连接池是指应用层自己维护的长时间连接队列，TP 框架本身并未实现这个机制。

• Db::connect() 每次调用都可能新建连接（取决于配置中的 deploy 和 pool_size 是否启用）
• TP 6.1+ 虽然加了 pool_size 配置项，但它只对 think-swoole 扩展生效，且依赖 Swoole 的协程上下文管理
• 纯 FPM 模式下设 pool_size 是无效的，连接数上限仍由 PHP-FPM 的 pm.max_children 和 MySQL 的 max_connections 共同决定

想用连接池，必须搭配 Swoole + think-swoole 扩展

只有在协程环境下，才能真正复用数据库连接。TP 原生的 Db 类在协程中默认不安全，必须通过 think-swoole 提供的 SwoolePool 代理或改用 CoMysql 客户端。

• 安装扩展：composer require topthink/think-swoole，再按文档启用协程数据库驱动
• 配置需显式开启：'pool_size' => 20、'timeout' => 3.0，否则协程连接会卡死或超时抛出 Swoole\Coroutine\MySQL\Exception
• 注意 Db::transaction() 在协程中要配合 go() 使用，否则事务会跨协程泄漏
• 常见错误现象：SQLSTATE[HY000] [2002] Connection refused，往往是 pool_size 设得太大，超过 MySQL 允许的最大连接数

TP 5.1 和 TP 6 的配置项行为差异很大

同样叫 pool_size，在两个版本里根本不是一回事：TP 5.1 的 pool_size 是伪配置（仅影响日志和提示），而 TP 6.1+ 的 pool_size 只在 think-swoole 下起效。

• TP 5.1 的数据库配置里写 'pool_size' => 10，实际完全不生效，连接还是走 PDO 短连
• TP 6.0 默认不加载 think-swoole，即使写了 pool_size，Db 类初始化时也会直接忽略该字段
• 检查是否生效最简单的方法：在协程中连续执行 Db::query('SELECT CONNECTION_ID()') 多次，看返回的 ID 是否重复

高并发下更关键的是连接复用策略，不是单纯调大 pool_size

盲目增大 pool_size 反而容易触发 MySQL 的 max_connections 限制，导致新请求被拒绝。真正有效的做法是控制协程内连接生命周期 + 合理设置空闲回收时间。

立即学习“PHP免费学习笔记（深入）”；

• 推荐初始值：pool_size 设为 MySQL max_connections 的 60%～70%，再根据压测结果微调
• 必须配 'idle_timeout' => 60，否则空闲连接长期占着不放，会撑爆数据库连接数
• FPM 场景下别折腾连接池，应优先优化查询本身（索引、批量操作、读写分离）和 PHP-FPM 进程模型
• 一个容易被忽略的点：Swoole 的 mysql.pool_size 和 TP 的 pool_size 是两套配置，前者控制底层协程 MySQL 客户端实例数，后者控制 TP 封装层的连接获取逻辑，二者需协同设置