MySQL 8.0原子DDL崩溃后自动回滚，因其将元数据更新等封装进隐式InnoDB事务，由redo/undo日志驱动恢复；仅ADD COLUMN（末尾）、DROP COLUMN（非全文索引列）等官方标注“Atomic DDL supported: Yes”的操作受保护，跨库RENAME、MODIFY COLUMN等不支持原子性。
MySQL 8.0 的原子 DDL 不需要你“手动触发回滚”，只要语句本身受支持、没提交，崩溃或报错后所有变更自动消失——查 SHOW CREATE TABLE 就是旧结构，不会残留半截字段或索引。
哪些 ALTER TABLE 操作真能回滚
原子性不是对所有 ALTER TABLE 都生效。只有官方文档标注 Atomic DDL supported: Yes 的操作才走完整事务流程：
-
ADD COLUMN（末尾添加，且不触发ALGORITHM=COPY） -
DROP COLUMN（InnoDB 表，非全文索引列） -
ADD INDEX/DROP INDEX（不含FULLTEXT） -
RENAME TABLE（同一 schema 内） -
ALTER TABLE ... ENGINE=InnoDB（隐式重建）
以下操作不保证原子性：MODIFY COLUMN、CHANGE COLUMN、OPTIMIZE TABLE、跨库 RENAME TABLE。它们失败时可能只回退部分步骤，比如删了索引但没删字段，或临时文件残留。
为什么 START TRANSACTION 包不住 DDL
在 START TRANSACTION 里写 ALTER TABLE 不仅没用，还会立刻报错：
ERROR 1785 (HY000): Statement violates GTID consistencyERROR 1305 (42000): SAVEPOINT does not exist
这不是配置问题，是 MySQL 明确禁止的：每条 DDL 都会隐式触发 COMMIT，它有自己的内部事务边界，不共享用户事务的 undo log 或隔离视图。唯一能靠显式事务兜底的场景，是 MySQL 8.0.23+ 的多表操作，比如 DROP TABLE t1, t2。
崩溃后怎么确认回滚真发生了
别光看错误信息是否报出，得交叉验证字典和物理状态：
- 执行
SHOW CREATE TABLE t1—— 结果必须是“全旧”或“全新”，绝不能出现“加了列但索引没建”或“字段名变了但类型没改” - 查
SELECT * FROM information_schema.INNODB_TABLES WHERE NAME = 'your_db/t1'—— 看SE_PRIVATE_DATA字段是否与预期结构一致（比如列数、版本号） - 检查数据目录：
ls /var/lib/mysql/your_db/—— 不该有#sql-*.ibd或#sql-*.frm这类中间文件；MySQL 8.0 崩溃后这些文件应该完全不存在
如果看到 ERROR 1033、ERROR 1286 或 ERROR 1872，说明数据字典和物理文件已脱节，原子 DDL 机制本身已失效，此时只能人工修复或重建表——这不是回滚问题，而是底层一致性被破坏了。
真正容易被忽略的点
原子 DDL 只管“改完或不改”，不管“能不能改”。以下问题仍会导致失败，且不触发事务级回滚：
- 目标表被长事务占用：查
information_schema.INNODB_TRX，确认没有运行超 60 秒的未提交事务 - MDL 锁等待超时：设
SET lock_wait_timeout = 5，避免 ALTER 卡死连接 - 混用不支持的操作：比如在同一个脚本里先跑
ALTER TABLE ... ALGORITHM=INSTANT，再跑MODIFY COLUMN，后者失败时前者已提交，不会回滚
INSTANT 快，但不等于安全；原子性只绑定操作类型，不绑定执行速度。验证是否生效，永远以 SHOW CREATE TABLE + INFORMATION_SCHEMA 为准，而不是看有没有报错。
