大量sleep连接（time>300秒）即为连接泄漏信号；主因是db::close()无效、事务未提交、静态变量持有连接、误用持久化等导致pdo未释放，与sql性能无关。
SHOW PROCESSLIST里大量Sleep连接就是泄露信号
别等报错才查。执行SHOW PROCESSLIST;，重点看Command列是Sleep、且Time持续增长（比如 >300 秒）的行——这些几乎全是未释放的 PDO 连接。它们不是“空闲”，而是被 PHP 脚本意外持有后没归还。
常见诱因包括：
- CLI 任务中调用了
Db::connect()但没在循环末尾加Db::close() - 事务里调了
$db->startTrans()，却漏写commit()或rollback()，尤其在try/catch里没兜住异常 - 把
Db实例赋值给了静态属性或全局变量（如self::$db），导致连接跨请求存活 - 用了
new \PDO()绕过框架，又没手动unset($pdo)或设$pdo = null
Db::close() 在多数场景下根本不起作用
Db::close()只关闭当前请求中「最后一次调用Db::connect()拿到的那个连接」，对事务内隐式创建的连接、模型自动获取的连接、协程环境下的连接完全无效。
更关键的是：
- TP6.1+ 的
Db::close()不触发底层PDO::__destruct()，只是清掉框架缓存的引用 - 在 Swoole 协程中，
Db::close()压根不走swoole_mysql驱动，等于白调 - TP5 没公开
Db::close()，有人用反射调Connection::destroy()，但它只销毁对象，不保证PDO断开，尤其开了PDO::ATTR_PERSISTENT => true时
pool.size 和 pool.timeout 不是泄露检测开关
ThinkPHP 没有内置连接泄露扫描器，pool.size、pool.timeout这些配置项控制的是连接复用池行为，不是“检测周期”。你配了pool.timeout => 60，它不会每 60 秒扫一遍哪些连接该关——它只在连接从池中取出后，若占用超时（注意：不是空闲超时），才主动销毁。
真正影响连接生命周期的只有两个参数：
-
pool.timeout：单位秒，连接被取出后未归还的最长容忍时间，超时即丢弃（非检测） -
break_reconnect：设为true时，连接异常断开会重建，但不会回收旧连接，反而可能加速耗尽
另外，idle_timeout在 TP6.1 中实际未生效；TP8 的'pool' => ['enable' => true]在 FPM 下完全被忽略。
持久连接（PDO::ATTR_PERSISTENT）在 FPM 下是泄漏加速器
TP6/TP8 默认用 PDO，但'persistent' => true这种写法无效。必须写进params数组：'params' => [PDO::ATTR_PERSISTENT => true]。可一旦开了，FPM 子进程退出时连接不真断，而是归还给 CGI 层，MySQL 看到的就是一堆Sleep连接长期挂着。
生产环境强烈建议显式禁用：
- TP6 配置中加
'params' => [PDO::ATTR_PERSISTENT => false] - TP8 若用 mysqli 驱动，
'pconnect' => true在 PHP 8+ 中风险更高，也建议关掉 - 真正可控的复用方案是 TP6 的
'deploy' => 1，它靠框架自己缓存 PDO 实例，不依赖底层持久化
最常被忽略的一点：连接是否泄漏，和你写的 SQL 是否慢、索引是否好，基本无关。它只取决于连接对象有没有在作用域结束前被释放——哪怕是一行代码的位置偏差，都可能导致几百个 Sleep 连接堆积。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
