MySQL 8.0原子DDL崩溃时自动回滚，因其将元数据更新、binlog写入等封装进隐式InnoDB事务，由redo/undo日志驱动崩溃恢复；不支持MyISAM表、跨库RENAME等操作，ERROR 1033/1286/1872表明字典与物理文件脱节。
MySQL 8.0 的原子 DDL 在崩溃时不需要你手动“触发回滚”，它会像普通 UPDATE 一样，由 InnoDB 崩溃恢复机制自动完成——只要事务没提交，所有变更（元数据更新、binlog 写入等）全丢，不留痕迹。
崩溃时的回滚不是靠 SQL，而是靠 redo/undo 日志
MySQL 8.0 把 ALTER TABLE 这类操作封装进一个隐式 InnoDB 事务：更新 mysql.columns、mysql.tables 等数据字典表，同步刷 binlog，还修改内存中的 dict_table_t。这些操作全部走标准事务路径，生成 redo 和 undo 记录。
一旦 mysqld 被 kill 或断电崩溃：
- 重启后 InnoDB 自动进入崩溃恢复阶段
- 扫描 redo log，发现该 DDL 事务没有
COMMIT标记 - 用 undo log 回滚所有已写入但未提交的数据字典变更
-
SHOW CREATE TABLE查到的永远是旧结构或新结构，绝不会出现“列加了但索引没了”
哪些操作真正受原子 DDL 保护
原子性只覆盖由事务性数据字典参与、且引擎支持的操作。别被名字带偏：
- ✅
CREATE TABLE、ALTER TABLE、DROP TABLE（InnoDB 表） - ✅
TRUNCATE TABLE（MySQL 8.0 起属于原子 DDL） - ✅
CREATE USER、GRANT、CREATE VIEW - ❌
RENAME TABLE t1 TO db2.t1（跨库不原子） - ❌
ANALYZE TABLE（不改元数据，无事务包装） - ❌ MyISAM 表的任何 DDL（仍依赖 .frm 文件，无事务兜底）
报 ERROR 1033 / 1286 / 1872？说明原子性已失效
这类错误不是语法错，而是数据字典和物理文件脱节的信号，常见于：
-
INFORMATION_SCHEMA.INNODB_SYS_TABLES里有记录，但/var/lib/mysql/db/t1.ibd文件缺失或权限不对 -
mysql.innodb_table_stats表损坏，Server 层无法确认引擎状态 - 升级后残留 5.7 的 .frm 文件，干扰了 8.0 数据字典一致性校验
此时原子 DDL 已无法挽救——崩溃恢复机制找不到匹配的 undo log，只能人工修复或重建。
真正关键的不是“怎么回滚”，而是“为什么能自动回滚”：因为元数据不再散落在文件系统和内存里，而统一存进 mysql.ibd，和其他业务表一样受 InnoDB 事务引擎管着。一旦你看到 Table definition has changed, please retry transaction，基本可以判定这不是 8.0 的原子 DDL 在工作，而是老机制残留或底层已损坏。
