如何设置ThinkPHP数据库连接池泄露检测周期，自定义扫描间隔时间？

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

ThinkPHP的数据库连接池（基于`think\db\Connection`和底层PDO）是一种懒连接+复用+自动释放机制，它没有内置的连接泄露扫描器、活跃心跳探测或超时回收逻辑。所谓的连接泄露检测周期在官方代码中基本不存在——即使你配置了，也可能无效。

常见错误现象：max_connections 被耗尽、MySQL 报错 Too many connections、show processlist 里大量 Sleep 状态长连接；但日志里找不到明确泄露点。

• ThinkPHP 不会主动扫描「哪些连接该关却没关」
• 连接是否泄露，取决于你的代码是否显式调用了 close()，或是否在协程/长生命周期脚本中意外持有了 Connection 实例
• 配置项如 pool.size、pool.timeout 控制的是连接复用池行为，不是泄露检测周期

真正能控制连接生命周期的是 pool.timeout 和 break_reconnect

这两个参数决定了连接在空闲多久后被主动丢弃，间接缓解「疑似泄露」问题——但它不是检测，而是兜底清理。

使用场景：高并发短请求（如 API）下，避免连接长期闲置占满池子；但对协程服务（如 Swoole）必须谨慎，因为连接可能跨请求复用。

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

• pool.timeout：单位秒，连接从池中取出后，若超过该时间未归还，会被自动销毁（注意：不是「空闲超时」，是「占用超时」）
• break_reconnect：设为 true 时，当连接异常断开，会尝试重建而非直接抛错；但不会触发泄露检查
• 示例配置：

  'mysql' => [ 'type' => 'mysql', 'hostname' => '127.0.0.1', 'database' => 'test', 'pool' => [ 'size' => 20, 'timeout'=> 60, // ⚠️ 这是「最长持有时间」，不是扫描间隔 ], ]

要查连接泄露，得靠 MySQL 侧 + 应用层日志交叉分析

ThinkPHP 没有埋点上报连接状态，所以必须自己加钩子或依赖外部工具。别指望改个配置就自动发现哪行代码忘了 $db->close()。

常见错误现象：Swoole Worker 内全局缓存了 Db::name('user') 查询对象、事务未 commit/rollback 就退出作用域、异常分支遗漏 finally { $conn->close() }。

• MySQL 侧执行 SHOW PROCESSLIST，重点关注 Command=Sleep 且 Time 值持续增长的连接，记下 Id 和 Info
• 在 ThinkPHP 配置中开启 debug 模式，并设置 log.sql 为 true，配合 trace 日志定位连接创建位置
• 关键点：连接泄露往往发生在「非标准请求生命周期」里，比如命令行任务、WebSocket 回调、定时器回调——这些地方 Db 实例容易被闭包捕获而无法释放

协程环境下必须手动管理连接，否则必泄露

Swoole 协程 + ThinkPHP 8.0+ 的 Connection 默认不是协程安全的，且不会自动绑定协程上下文。一旦你在 go 块里复用同一个 Db 实例，连接就会被多个协程争抢，导致状态错乱和连接卡死。

性能影响：一个泄露的连接会持续占用 MySQL 线程，叠加后直接拖垮 DB 吞吐；兼容性上，pdo_mysql 扩展在协程下需启用 mysqlnd 并开启 coroutine 支持。

• 正确做法：每次协程内用 Db::connect() 新建独立连接，或使用 Db::connection('name', true) 强制获取新实例
• 绝对避免：把 Db 实例赋值给全局变量、静态属性、或跨 go 传递
• 验证方式：在协程函数末尾加 echo Db::getPdo()->getAttribute(PDO::ATTR_CONNECTION_STATUS);，应输出 Connection OK；若报错或返回空，说明连接已失效或被其他协程污染

连接泄露不是配个时间就能解决的问题，它根植于代码对连接生命周期的理解是否准确——尤其在协程、长连接、多线程混合场景下，Db 实例的持有范围比你想的更危险。