ThinkPHP 6.0+ 原生不支持数据库连接池，仅在 Swoole + think-swoole 扩展下通过 pool_size 等配置实现协程连接复用；FPM 模式下 pool_size 无效，仍为短连接。
ThinkPHP 6.0+ 不自带数据库连接池
官方底层用的是 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设为 MySQLmax_connections的 60%～70%，再根据压测结果微调 - 必须配
'idle_timeout' => 60，否则空闲连接长期占着不放，会撑爆数据库连接数 - FPM 场景下别折腾连接池，应优先优化查询本身（索引、批量操作、读写分离）和 PHP-FPM 进程模型
- 一个容易被忽略的点：Swoole 的
mysql.pool_size和 TP 的pool_size是两套配置，前者控制底层协程 MySQL 客户端实例数，后者控制 TP 封装层的连接获取逻辑，二者需协同设置
