TRUNCATE无法回滚，因为它是DDL操作，执行前隐式提交事务、不写undo log，绕过事务管理器；重置AUTO_INCREMENT、释放数据页、清空统计信息，且在BEGIN; TRUNCATE; ROLLBACK;中表仍被清空。
TRUNCATE 无法回滚，因为它根本不在事务的管辖范围内——执行前就已隐式提交，且不写 undo log。
TRUNCATE 是 DDL，不是 DML
MySQL 把 TRUNCATE TABLE 归为数据定义语言（DDL），和 DROP、ALTER 同级。它操作的是表的元数据结构：重置 AUTO_INCREMENT 计数器、释放数据页、清空统计信息。这些动作绕过了事务管理器，不走行级处理路径，也不生成 undo log，自然没有回滚依据。
常见错误现象：
- 在
BEGIN; TRUNCATE TABLE t; ROLLBACK;中，表照样被清空 - Spring 的
@Transactional方法里调用TRUNCATE，异常抛出后表已空，事务回滚不包含它 - 用
SET autocommit = 0关闭自动提交，仍无法阻止TRUNCATE隐式提交
TRUNCATE 执行前就强制提交当前事务
哪怕你前面刚执行了 INSERT 或 UPDATE，只要语句流中出现 TRUNCATE TABLE，MySQL 就会在真正执行它之前，先把当前事务里所有未提交的 DML 强制 COMMIT。之后才处理 TRUNCATE 本身。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
这意味着：
-
ROLLBACK只能作用于一个空事务，对已提交的 DML 和已完成的TRUNCATE都无效 - 错误提示（如表不存在）出现时，前面的 DML 早已落盘，无法补救
- 主从复制中，
TRUNCATE在 binlog 中只记一条语句（SBR 模式），无法按时间点闪回某几行误删数据
外键、权限、锁行为全都不一样
TRUNCATE 不是 DELETE 的“加速版”，而是另一条完全不同的执行路径：
- 遇到外键引用会直接报错：
ERROR 1701 (HY000): Cannot truncate a table referenced in a foreign key constraint，不能靠SET FOREIGN_KEY_CHECKS = 0绕过 - 需要
DROP权限，而非DELETE权限 - 执行时需获取元数据锁（MDL），若表上有长事务或活跃查询，
TRUNCATE会卡在system lock状态，甚至导致主库夯住 - 不触发
DELETE触发器，也不支持WHERE条件
真正关键的不是“能不能快”，而是“有没有退路”。一旦把 TRUNCATE 放进任何依赖回滚逻辑的流程里，就等于主动放弃了事务边界——这点在归档脚本、定时任务、测试数据清理等场景里最容易被忽略。
