ThinkPHP如何配置修改数据库连接池参数_提升高并发性能-ThinkPHP-PHP中文网

thinkphp 8 连接池配置需通过 think-swoole 扩展在 config/swoole.php 的 database 节点下设置，启用 enable=true 并配置 min_connections、max_connections 等参数；原生 tp8 不支持连接池，database.php 中添加 pool 相关字段无效。

thinkphp如何配置修改数据库连接池参数_提升高并发性能

ThinkPHP 8 连接池配置在哪改

ThinkPHP 8 默认不启用连接池，mysql 或 pdo_mysql 驱动本身也不提供连接池功能——所谓“连接池参数”实际是通过 Swoole 或 Hyperf 等协程服务器 + 自定义数据库连接管理器实现的。原生 TP8 的 database.php 配置里没有 pool、max_connections 这类字段，硬加会无效。

如果你用的是 think-swoole 扩展（官方维护），连接池能力才真正存在，配置入口在 config/swoole.php 中的 database 节点下：

'database' => [
    'enable' => true,
    'min_connections' => 5,
    'max_connections' => 50,
    'wait_timeout' => 3.0,
    'heartbeat' => 30,
],

enable 必须设为 true，否则即使其他参数写了也走默认短连接
min_connections 是协程启动时预创建的连接数，设太低会导致首请求延迟；设太高可能占满 MySQL max_connections
max_connections 不是“最多允许多少个并发查询”，而是连接池中最多维持多少个空闲+忙碌的连接总和
wait_timeout 是协程等待空闲连接的超时时间（秒），设太小容易抛出 ConnectionPoolTimeoutException

为什么改了 pool 参数没效果

常见现象：配了 max_connections => 100，压测时还是卡在 20 QPS，日志里反复出现 Too many connections 或 Connection refused。

根本原因不是 TP 配置错了，而是没对齐三层限制：

MySQL 侧：max_connections 全局变量必须 ≥ 池上限（比如你池设 50，MySQL 却只允许 30，多余连接直接被拒）
Swoole Worker 数：swoole.server.worker_num 若设为 4，那最多只有 4 个进程能从池里取连接，哪怕池里有 100 个也没用
协程并发量：go(function () { ... }) 启的协程数若远超 max_connections，就会排队等连接，而非并行执行

验证方法：在控制器里打印 Swoole\Coroutine\Channel 当前长度，或用 DB::getPdo() 查当前连接是否复用成功（同一协程内多次调用返回相同 PDO 实例）。

pdo_mysql 和 mysqlnd 驱动对连接池的影响

TP8 默认用 pdo_mysql，但它在协程环境下有严重隐患：PDO 实例不是协程安全的，多个协程共用一个 PDO 可能导致 MySQL server has gone away 或字段错乱。

必须切换到 mysqlnd + swoole_mysql 兼容层（由 think-swoole 自动适配），才能保证连接真正可复用且线程/协程安全。

确认已安装 mysqlnd：运行 php -i | grep mysqlnd，有输出才算生效
检查 php.ini 中未禁用 mysqlnd 相关扩展（如 extension=mysqli 和 extension=pdo_mysql 可保留，但底层协议要走 mysqlnd）
如果用的是阿里云 RDS 或腾讯云 CDB，注意它们默认关闭 wait_timeout 和 interactive_timeout，建议调高至 300 秒以上，避免连接池里的空闲连接被服务端主动断开

连接池参数调优的关键观测点

别只盯着 QPS 上升，这些指标更关键：

MySQL Threads_connected 是否稳定在 min_connections ~ max_connections 区间？突增说明连接泄漏
TP 日志中是否频繁出现 ConnectionPool::pop(): timeout？说明 wait_timeout 太短或 max_connections 不足
用 swoole_server->stats() 查 connection_count 和 tasking_num，若后者长期 > 0，说明协程任务积压，瓶颈不在 DB 层
单次请求中 DB::table()->select() 调用次数是否过多？连接池缓解的是连接建立开销，不是 SQL 执行本身；N+1 查询照样拖垮性能