MySQL 事务里 TRUNCATE TABLE 为什么回滚不了：一次误清空临时表的事故复盘

报表任务凌晨重跑时，值班同学先清空了临时表，转头才发现新批次文件还没完成落盘。习惯性执行 ROLLBACK 后，rpt_daily_orders_tmp 仍然是空的。这个结果不是锁没释放，而是 TRUNCATE TABLE 已经把事务边界切开了。

在 MySQL 中，TRUNCATE TABLE 会隐式提交当前事务，不能依靠后续的 ROLLBACK 恢复已清空的数据。线上清理可回退数据时，优先使用带条件的分批 DELETE，或先做明确命名的备份表。

事故现场：清空动作成功，回滚动作也“成功”

问题发生在报表重跑脚本里。脚本先建立当天的中间结果，再把旧数据清掉：

START TRANSACTION;
SELECT COUNT(*) AS before_rows
FROM rpt_daily_orders_tmp;

TRUNCATE TABLE rpt_daily_orders_tmp;
ROLLBACK;

SELECT COUNT(*) AS after_rows
FROM rpt_daily_orders_tmp;

测试环境里，before_rows 是 18642，最后的 after_rows 却是 0。客户端没有报“回滚失败”，只是把没有可回滚事务当成一次普通结束处理。真正需要追问的是：哪条语句改变了事务状态？

时间线：TRUNCATE TABLE 在什么时候切断了回退窗口

把每条语句单独运行，并在前后观察事务边界，现象会清楚很多：

1. START TRANSACTION 开启事务，旧数据仍可由事务控制。
2. TRUNCATE TABLE 执行表级清空，并在语句前后触发隐式提交。
3. 此时原来的事务已经结束，后面的 ROLLBACK 没有旧数据可以恢复。

这里别急着把责任归给客户端。MySQL 的规则决定了这条语句不能和普通 InnoDB 行修改一样理解。即使表使用的是 InnoDB，存储引擎支持事务，也不意味着所有 SQL 都参加同一个回滚模型。

为什么 DELETE 可以回滚，TRUNCATE 不行

DELETE FROM rpt_daily_orders_tmp 是按行修改数据，受当前事务控制；TRUNCATE TABLE 通过 DDL 语义快速重置表，涉及表定义和空间处理，执行前后会提交事务。两者都能让查询结果变成零行，但恢复能力完全不同。

START TRANSACTION;
DELETE FROM rpt_daily_orders_tmp
WHERE stat_date = '2026-07-26';

SELECT COUNT(*)
FROM rpt_daily_orders_tmp
WHERE stat_date = '2026-07-26';

ROLLBACK;

这段实验的重点不是证明 DELETE 永远安全，而是提醒：只要需要回退，就必须先确认语句类型、影响行数和锁等待。大批量删除仍然可能拖慢线上事务。

根因定位：把“清空表”误当成一个可回滚动作

复盘脚本后，事故根因有三层。第一层是操作认知：团队把 TRUNCATE 当成了速度更快的 DELETE。第二层是流程缺口：清理前没有记录行数，也没有生成备份表。第三层是验收缺口：脚本只检查 SQL 返回成功，没有检查清理后是否仍有可用的输入文件和目标行数。

可以用下面的检查把“我以为事务还在”变成证据：

SELECT TABLE_NAME, TABLE_ROWS
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'rpt_daily_orders_tmp';

SHOW CREATE TABLE rpt_daily_orders_tmp;

TABLE_ROWS 在某些存储引擎上只是估算值，不能代替精确的 COUNT(*)。它适合快速看表是否异常，最终验收仍要用业务日期和批次字段核对。

修复方案：把清理动作拆成可核对的几个阶段

这次恢复没有继续尝试回滚，而是从最近一次导出的压缩文件恢复临时表，再按批次重跑。以后清理 rpt_daily_orders_tmp，采用下面的顺序：

1. 先把当前批次、预计行数和数据来源写入任务日志。
2. 需要保留回退能力时，创建带时间后缀的备份表，例如 rpt_daily_orders_tmp_bak_20260726，并核对行数。
3. 只删除确认范围内的数据，优先按主键或日期分批执行，每批记录影响行数。
4. 导入新批次后，同时核对总行数、日期范围和业务主键重复数。

CREATE TABLE rpt_daily_orders_tmp_bak_20260726
LIKE rpt_daily_orders_tmp;

INSERT INTO rpt_daily_orders_tmp_bak_20260726
SELECT * FROM rpt_daily_orders_tmp;

SELECT COUNT(*) FROM rpt_daily_orders_tmp_bak_20260726;

如果数据量太大，备份表本身也要纳入容量评估；不能为了获得回退能力，突然把磁盘写满。更稳妥的做法是保留原始分区文件或对象存储导出，并把恢复演练纳入报表任务的发布检查。

防复发：给危险清理语句加上可见的门槛

脚本层面可以把危险动作挡在人工确认前。比如先执行只读预览，要求输入批次号，再根据行数阈值决定是否继续。对于服务账号，限制它对生产表执行 DDL；需要重建临时表时，用专门的维护账号和审批记录承接。

• 脚本禁止直接拼接表名，清理目标从白名单映射而来。
• 影响行数超过阈值时停止，不自动进入下一批。
• 任务日志保存清理前后行数、批次号、操作者和恢复位置。
• 发布前用测试库验证空批次、重复批次和恢复失败三种状态。

常见问题：事务清理表时还要注意什么

TRUNCATE TABLE 执行后还能撤销吗？

不能指望当前事务的 ROLLBACK 撤销它。要恢复数据，应使用备份、导出文件或存储层恢复能力。

临时表也需要防止误清空吗？

需要。临时表的数据可能是唯一的中间结果，尤其在输入文件尚未落盘时，清空它同样会让重跑失去依据。

大表可以直接改成 DELETE 吗？

不要直接替换后上线。先按主键或时间范围做小批量实验，观察锁等待、日志量和任务耗时，再决定批大小。

如何确认恢复后的表可用？

同时核对精确行数、业务日期范围、主键重复数和下游报表抽样结果，只看 SQL 返回成功是不够的。

总结：先设计回退，再选择清理语句

TRUNCATE TABLE 适合明确知道数据可再生、且不需要当前事务回退的场景。线上任务一旦涉及人工重跑、外部文件、报表中间结果或不可重复的业务输入，就应先安排备份和核对，再选择分批 DELETE 或其他可恢复方案。速度是清理动作的一部分，可回退性才是事故成本的另一半。