PHP PDO 事务里执行 DDL 为什么可能自动提交

先给结论：PDO::rollBack() 能回滚的前提，是数据库仍把这些语句放在同一个可回滚事务里。PDO_MYSQL 连接 MySQL 时，CREATE TABLE、ALTER TABLE、DROP TABLE、TRUNCATE TABLE 等 DDL 可能让 MySQL 对当前事务执行隐式提交，所以前面已经成功的 INSERT 或 UPDATE 不能再靠 rollBack() 撤销。这里不是 PDO 自己“偷偷提交”，而是驱动把请求交给了数据库，最终边界由数据库规则决定。

官方参考：https://www.php.net/manual/en/pdo.transactions.php　https://dev.mysql.com/doc/refman/8.4/en/implicit-commit.html

一次“回滚成功但数据还在”的故障现场

这类问题通常出现在初始化或升级脚本：先给新租户插入一条配置，再创建索引或新增字段，后面的语句失败，代码进入 catch 并调用 rollBack()。开发者看到异常，以为配置也会消失；重查数据库却发现配置已经存在，甚至表结构也已改变。

我排查时会先按时间线拆开：beginTransaction() 开始事务，DML 暂存；DDL 到达 MySQL 后触发它自己的提交边界；之后 PHP 再调用 rollBack()，已经提交的部分当然没有可回滚的版本。这个顺序比盯着异常信息更重要。

先把事务边界画出来：DDL 可能切断回滚

PHP 手册明确提醒，部分数据库在事务中执行 DDL 时会隐式 COMMIT。MySQL 8.4 的文档则列出了大量会结束活动事务的语句，包括 ALTER TABLE、CREATE INDEX、CREATE TABLE、DROP TABLE、TRUNCATE TABLE 等。

最小复现只用于说明边界：

beginTransaction();

// 这条业务数据原本期待随事务一起回滚。
$pdo->exec("INSERT INTO account_flags (account_id, enabled) VALUES (7, 1)");

// PDO_MYSQL 将 DDL 交给 MySQL；具体提交语义由数据库决定。
$pdo->exec("CREATE TABLE migration_probe (id INT PRIMARY KEY)");

// 对 MySQL 的这类场景，rollback 不能撤销已经隐式提交的 INSERT。
$pdo->rollBack();

不要把“原子 DDL”理解成“业务事务里的可回滚 DDL”。MySQL 文档区分了两者：原子 DDL 保证这条 DDL 自己要么完成、要么在服务器异常时恢复；它仍然会结束当前活动事务。数据库换成 PostgreSQL、SQLite 或其他引擎时，规则还可能不同，因此不要只看 PDO API 名称下结论。

修复方案：把结构迁移和业务事务拆开

更稳的组织方式是把 DDL 当成迁移步骤，把 DML 当成业务事务。部署阶段先由迁移工具或独立脚本执行结构变更，确认 schema ready 后，应用代码再在一个只包含业务数据操作的 PDO 事务中提交。

exec("ALTER TABLE account_flags ADD COLUMN source VARCHAR(32) NULL");

try {
    $pdo->beginTransaction();
    // 业务事务只放可预期的 DML，失败时可以完整回滚。
    $stmt = $pdo->prepare(
        "INSERT INTO account_flags (account_id, enabled, source) VALUES (?, 1, ?)"
    );
    $stmt->execute([7, 'migration']);
    $pdo->commit();
} catch (Throwable $e) {
    // 只在事务仍由当前 PDO 连接持有时回滚，并把原异常继续抛出。
    if ($pdo->inTransaction()) {
        $pdo->rollBack();
    }
    throw $e;
}

如果迁移失败，回退动作也应由迁移系统负责，例如准备反向迁移、恢复备份或先发布兼容代码；不要假设业务事务的 rollBack() 能恢复已修改的表结构。对于新增字段这类变更，常见的安全顺序是“先加可空字段，再发布兼容代码写入，最后再收紧约束”，把结构发布和数据发布分成可观察的阶段。

排查时看这张边界清单

常见问题

PDO::beginTransaction() 成功就代表所有 SQL 都能回滚吗？

不代表。PDO 只能在驱动层判断事务能力，数据库运行时仍可能因为 DDL、表引擎或语句规则改变边界。

把 DDL 放在 savepoint 之后能解决吗？

不能把数据库不支持的回滚语义变出来。savepoint 只能在当前事务仍有效且数据库允许该语句回滚时发挥作用，不能抵消隐式提交。

DDL 和 DML 必须永远分开吗？

应以具体数据库文档为准；在 PDO_MYSQL + MySQL 的生产迁移中，分开执行更容易观察、重试和回退，也能避免把业务数据误认为可恢复。

判断这类问题的关键不是“有没有调用 rollBack()”，而是“执行 DDL 前后，数据库是否仍处在同一个可回滚事务中”。先确认驱动和数据库规则，再设计迁移边界，通常比在异常处理里反复补一行回滚更有效。