本文目录导读：
- 文章标题：PHP连接泄露怎么排查？从现象到根因的实战指南（附代码级诊断）
- 现象识别：不是所有“慢查询”都是SQL的锅
- 根因分析：三大典型“隐形杀手”
- 排查工具箱：三步锁定真凶
- 代码级修复：三招立即止血
- 常见问答（FAQ）
PHP连接泄露怎么排查？从现象到根因的实战指南（附代码级诊断）
📚 目录导读
- 现象识别：如何判断你的PHP应用确实存在连接泄露？
- 根因分析：连接泄露的三大典型来源（PDO、MySQLi、Redis/多进程）
- 排查工具箱：从
SHOW PROCESSLIST到strace，再到debug_backtrace的实战组合拳 - 代码级修复：防止连接泄露的最佳实践（长连接陷阱与析构函数）
- 常见问答（FAQ）：关于连接池、超时设置、ORM框架的疑虑解答
现象识别：不是所有“慢查询”都是SQL的锅
当你的PHP-FPM进程数飙升到pm.max_children上限，数据库Threads_connected持续高位（远超实际并发），且SHOW PROCESSLIST里堆满Sleep状态的连接时，大概率就是连接泄露。
最典型的症状组合：
- 错误日志出现
PDOException: SQLSTATE[HY000] [2002] Connection refused（数据库连接数打满） - 或
Can't connect to MySQL server (Too many connections) - 页面请求变慢,但
top看到PHP进程CPU不高
关键区别：普通慢查询是Query状态持续时间长；而泄露导致的假连接是Sleep状态，且Time字段不断累加（如持续几十秒甚至几分钟不释放）。
根因分析：三大典型“隐形杀手”
杀手1：PDO或MySQLi的“假释放”
这是最常见的坑,当你使用PDO或mysqli时，如果未显式设置$pdo = null;，或依赖PHP脚本结束自动释放，但在长生命周期脚本（如Swoole常驻进程、旧版PHP-FPM的request_terminate_timeout设置过长）中，连接会一直挂在进程里。
// 错误示范：函数返回后，$pdo仍然被垃圾回收机制延迟清理
function getUser($id) {
$pdo = new PDO('mysql:host=...', 'user', 'pass');
$stmt = $pdo->query("SELECT ...");
return $stmt->fetch();
}
// 没有unset($pdo)，在循环10万次时，连接堆积
杀手2：MySQLi的persistent连接陷阱
在mysqli_connect或PDO的DSN中加上pconnect或ATTR_PERSISTENT => true，本意是复用连接，但如果连接池中的连接被数据库端超时断开（wait_timeout），PHP-FPM进程却不知道，当再次使用时，会抛出MySQL server has gone away。此时程序若捕获异常后未重新建立连接，而是继续使用旧连接，就会导致PHP再次发起新连接，旧连接残留。
杀手3：多进程/异步框架中的资源未回收
在workerman或Swoole中，每个Worker进程内创建的数据库连接，如果写在全局变量或静态属性里，且没有在onClose或析构时清理，一旦数据库断开，就会无限重连导致文件描述符耗尽。
排查工具箱：三步锁定真凶
第一步：用SHOW PROCESSLIST揪出“僵尸连接”
SHOW PROCESSLIST; -- 重点观察：Command='Sleep'、Time > 10 且不断增多的连接 -- 记录其ID，12345
第二步：用strace追踪某个PHP-FPM进程的系统调用
# 找到进程ID（5678）
strace -p 5678 -e trace=network -f -o /tmp/php_strace.log
# 复现业务操作后，查看log
grep 'connect(' /tmp/php_strace.log | tail -n 20
如果看到大量的connect()返回成功，且close()次数远少于connect()次数，说明连接确实没有被关闭。
第三步：在PHP代码中注入debug_backtrace快照
在PDO构造函数或析构函数中临时加入日志：
class DebugPDO extends PDO {
function __construct($dsn, $user, $pass) {
parent::__construct($dsn, $user, $pass);
file_put_contents('/tmp/pdo_debug.log',
date('Y-m-d H:i:s') . " NEW CONN " . json_encode(debug_backtrace()) . PHP_EOL, FILE_APPEND);
}
function __destruct() {
file_put_contents('/tmp/pdo_debug.log',
date('Y-m-d H:i:s') . " CLOSE CONN " . spl_object_id($this) . PHP_EOL, FILE_APPEND);
}
}
筛选NEW CONN与CLOSE CONN的数量差，若持续增加，则定位到具体创建连接的文件与行号。
代码级修复：三招立即止血
修复1：强制“用完即毁”
function getUserData($id) {
$conn = new PDO(...);
try {
// 业务逻辑
} finally {
$conn = null; // 关键：无论是否异常，立即释放
}
}
修复2：关闭持久化，或设置合理的超时
若必须使用pconnect，请在MySQL端设置wait_timeout为较短值（如60秒），并确保PHP的mysql.connect_timeout（默认60）比它小。在每次数据库操作前检查连接有效性：
if ($pdo->query('SELECT 1') === false) { // 旧连接不可用
$pdo = new PDO(...); // 重建连接
}
修复3：框架级统一管理（容器模式）
使用依赖注入容器（如Laravel的DB门面），并配置连接池。禁止在模型或服务类中直接new PDO，而是通过一个ConnectionManager单例来获取，并在析构时统一清理。
常见问答（FAQ）
Q1：我的PHP脚本是纯CLI运行的，执行完就退出了，还需要手动释放连接吗？ A： 如果是短脚本（<1秒），PHP的进程退出会强制关闭所有连接，不需要，但如果是长驻内存的守护进程（如消费队列的脚本），不释放就会耗尽连接。
Q2：连接泄露和连接池是一回事吗？ A： 不是，连接池是有界复用，而泄露是无限增长，连接池超出上限时，会排队或报错；泄露则只会持续新增连接直到数据库崩掉。
Q3：使用了PDO的ATTR_EMULATE_PREPARES => false会导致泄露吗？
A： 不会，这个选项只是影响预处理语句的发送方式，与连接生命周期无关，泄露的核心在于未调用$conn = null 或 静态属性持有对象。
Q4：如何用监控工具提前预警？
A： 建议在PHP-FPM的pm.status_path开启状态页，观察active-processes与max-children-reached，数据库侧用Prometheus + mysqld_exporter监控Threads_connected超过阈值的告警。
Q5：Windows下的Apache + PHP模块环境是不是更容易泄露？
A： 是的，Apache的mpm-win32模块模式下，PHP作为mod_php常驻内存（没有request_terminate_timeout），如果代码写得不干净，连接会越积越多。解法是改用PHP-FPM（配合Nginx）或强制在代码中对每个请求完成finally清理。
排查连接泄露,不要猜，用数据说话，先用SHOW PROCESSLIST确认现象，再用strace或代码日志定位创建连接的堆栈，最后用finally和容器化思想修复。只要记住“谁创建，谁负责close”，就能根治大部分问题。
