TRUNCATE 是不可回滚的 DDL 操作，它重置 auto_increment、释放数据页、不写 undo log，执行即隐式提交；DELETE 才是可回滚的 DML 操作。
TRUNCATE 是 DDL，不是 DML
MySQL 把 TRUNCATE TABLE 归类为数据定义语言（DDL），和 CREATE、DROP、ALTER 同级。它操作的是表的元数据结构——比如重置 auto_increment 计数器、释放数据页、清空统计信息，而不是逐行修改数据。因此，它绕过了事务管理器（transaction manager）的调度路径，不进入 undo log 流程。
对比之下，DELETE FROM 是 DML，每行删除都会写入 undo log，事务未提交前可回滚；而 TRUNCATE 执行即隐式触发 COMMIT，哪怕你已执行 SET autocommit = FALSE 也无效。
InnoDB 和 MyISAM 都不支持 TRUNCATE 回滚
虽然不同引擎实现细节有差异，但回滚能力上完全一致：都不支持。
- InnoDB：直接丢弃所有数据页，重置
auto_increment到 1（或指定值），不记录行级日志，ROLLBACK对其无感知 - MyISAM：清空数据文件（.MYD）并重写头信息，元数据立即落盘，同样不可逆
- MEMORY 引擎同理，数据在内存中被整体释放，无回滚上下文
别信“某些版本/配置下能回滚”的说法——截至 2026 年，所有主流 MySQL 版本（5.7 / 8.0 / 8.4）对所有内置引擎，TRUNCATE 均为不可回滚操作。
为什么用 TRUNCATE 却期望回滚？常见误用场景
最典型的是在 Spring @Transactional 方法里混用 TRUNCATE，以为异常时能自动回滚前面的操作。结果是：表已清空，事务后续失败，但 TRUNCATE 不撤回，数据永久丢失。
这类问题往往暴露在以下情况：
- ETL 脚本先
TRUNCATE再INSERT，插入中途失败 → 表空着上线 - 测试环境用
TRUNCATE清洗数据，误跑进生产事务块 - 误以为
TRUNCATE和DELETE只是“快慢之分”，忽略语义层级差异
真正需要事务安全的清空动作，必须用 DELETE FROM table_name，哪怕加个 WHERE 1=1 也比 TRUNCATE 可控。
替代方案要兼顾性能与安全
如果表很大，DELETE FROM 又太慢，不能简单换 TRUNCATE 了事。得拆解真实瓶颈：
- 若只是怕长事务锁表：用分批
DELETE+WHERE id BETWEEN ? AND ?，控制每次 1k~10k 行 - 若需极速清空且接受风险：确认该表无业务依赖、有备份、有快速恢复预案，再用
TRUNCATE - 若涉及分区表：优先考虑
ALTER TABLE ... DROP PARTITION，它也是 DDL，但影响范围可控，且部分场景可配合EXCHANGE PARTITION实现准原子切换
关键点始终只有一个：DDL 操作没有“中间态”，一旦发出，就不再属于你的事务边界。别把它放进任何依赖回滚逻辑的流程里。
