PHP PDO 持久连接怎么选：连接池边界、事务隔离与故障恢复

PHP-FPM 的 worker 数量一上去，PDO 持久连接很容易被误当成“自动连接池”。它只能复用同一 PHP 进程留下的数据库连接，不能替应用管理全局连接上限，也不会替你处理上一次请求遗留的事务。更稳妥的做法是先按数据库连接预算决定是否启用，再把事务、健康检查和一次性恢复写进代码路径。

持久连接适合连接建立成本高、每个 worker 请求模式稳定的场景；如果数据库连接数紧张、租户隔离复杂或请求经常改变会话变量，普通连接往往更容易控制。

先按负载约束决定连接模式

PDO 的 PDO::ATTR_PERSISTENT 会让连接留在当前 PHP 进程中，后续请求有机会复用它。PHP-FPM 的每个 worker 都有自己的进程空间，所以 20 个 worker 可能对应 20 条持久连接；数据库端还要加上后台任务、管理工具和复制通道的连接。

可以先做一个保守预算：PHP-FPM worker 数 × 每个 worker 的持久连接数 + 其他连接。结果接近数据库的 max_connections 时，不要用持久连接掩盖容量问题。短请求、连接建立很快且连接数敏感的服务，普通连接更可预测。

把连接配置和事务边界放在同一条路径

下面的工厂只负责建立 PDO，业务方法负责事务。这样连接参数不会散落在控制器里，事务的开始、提交和回滚也能被完整审查。

 PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
        PDO::ATTR_PERSISTENT => $config['persistent'],
    ]);
}

function createOrder(PDO $pdo, int $userId, int $amount): void
{
    $pdo->beginTransaction();
    try {
        $insert = $pdo->prepare('INSERT INTO orders (user_id, amount, status) VALUES (?, ?, ?)');
        $insert->execute([$userId, $amount, 'pending']);
        $pdo->commit();
    } catch (Throwable $error) {
        if ($pdo->inTransaction()) {
            $pdo->rollBack();
        }
        throw $error;
    }
}

这里的关键不是把 PDO::ATTR_PERSISTENT 永远设为 true，而是让 beginTransaction、commit 和 rollBack 成为一条闭合路径。orders 写入成功后才提交；异常时先确认仍在事务中，再回滚。

持久连接最容易留下的会话状态

复用连接意味着会话变量、字符集、SQL 模式和未完成事务都可能延续到下一次请求。应用启动时设置一次还不够，连接交给业务方法前应确认关键会话条件；事务结束后也不要把连接对象当成“天然干净”。

尤其要避免在一个请求里改变隔离级别、时区或临时表后直接返回。若确实要改变，必须在同一个业务边界内恢复，或者关闭持久连接，让下一次请求拿到全新会话。

断线恢复只在幂等操作上重试一次

持久连接可能遇到数据库重启、空闲连接被中间设备回收或服务端主动断开。捕获 PDOException 后可以重建连接，但不能对已经提交一半的扣款、发货或库存操作盲目重试。下面的示例只对“读取订单状态”这类幂等查询允许一次恢复。

prepare('SELECT id, status, amount FROM orders WHERE id = ?');
            $query->execute([$orderId]);
            return $query->fetch();
        } catch (PDOException $error) {
            if ($attempt === 1) {
                throw $error;
            }
            $pdo = makePdo($config);
        }
    }
    return false;
}

恢复动作是“重建连接后再查一次”，不是无限重试。若写操作已经改变外部状态，应改用业务幂等键、结果查询或人工补偿，不要把同一个写请求直接再发一遍。

上线前的选择清单

• 按 PHP-FPM worker 和后台任务计算连接预算，并给数据库管理操作留余量。
• 确认每个事务都有成功提交和异常回滚分支。
• 检查连接初始化时的字符集、错误模式和必要会话参数。
• 只对幂等读操作设置一次恢复；写操作需要幂等键或补偿方案。

相关问题

PDO 持久连接会被所有 PHP-FPM worker 共享吗？

不会。它按进程复用，worker 之间不共享同一个 PDO 连接，因此连接预算要按 worker 数估算。

事务异常时一定要调用 rollBack 吗？

业务代码应显式回滚，并先用 inTransaction() 判断边界；这样异常路径不会把未完成事务留给后续请求。

数据库重启后可以自动重试所有 SQL 吗？

不可以。只有能证明幂等的查询或带幂等键的操作适合一次重试，扣款、库存等写操作需要先确认服务端状态。

最后确认

PDO 持久连接的价值在于减少重复建连，不在于替代连接池、事务管理或故障恢复。先做连接预算，再固定事务收口和恢复边界，才能让复用带来的收益不变成跨请求状态污染。