MySQL 8.0原子DDL通过将元数据操作（如更新mysql.columns、mysql.tables）纳入标准InnoDB隐式事务，并结合innodb_ddl_log表管控物理文件操作，确保崩溃时全部自动回滚，杜绝中间态；仅限InnoDB表及明确支持的DDL语句生效。
崩溃时所有元数据变更自动回滚，靠的是InnoDB事务机制本身
MySQL 8.0 的原子 DDL 不是额外加了一层“DDL事务”，而是把元数据操作（如向 mysql.columns 插入列定义、更新 mysql.tables 的版本号）全部塞进标准 InnoDB 隐式事务里。这意味着：一旦崩溃发生在 ALTER TABLE 执行中途，InnoDB 崩溃恢复流程会像处理一个未提交的 UPDATE 一样，直接用 undo log 回滚整个事务——你重启后查 SHOW CREATE TABLE，看到的永远是完整的旧结构或完整的新结构，绝不会出现“新加了列但索引丢了”或者 Table definition has changed, please retry transaction 这类中间态报错。
物理文件操作也被纳入原子控制，靠 mysql.innodb_ddl_log 表兜底
光靠字典表回滚还不够：重命名 .ibd 文件、删除旧表空间这些动作本身不是事务性的。MySQL 8.0 用 mysql.innodb_ddl_log（藏在 mysql.ibd 里）记录前滚/回滚指令，确保这类文件操作只在 post-DDL 阶段执行。例如 RENAME TABLE 实际分两步：先在事务内完成字典更新，再在事务提交后由专用线程按 innodb_ddl_log 记录执行文件重命名。如果崩溃发生在这一步之前，重启后该日志会被扫描并触发清理；如果发生在之后但未完成，日志会驱动重试。这避免了 MySQL 5.7 中常见的 #sql-xxxxx.ibd 残留问题。
不是所有 ALTER 都受保护，必须确认操作类型和存储引擎
原子性只覆盖明确标注 “Atomic DDL supported: Yes” 的操作，且仅对 InnoDB 表生效。常见误区包括：
-
MODIFY COLUMN和CHANGE COLUMN❌ 不受原子保护——它们触发重建表流程，绕过事务字典路径 -
ALGORITHM=INSTANT✅ 快，但 ≠ 原子；它只是跳过数据拷贝，元数据变更仍走原子路径 -
DROP DATABASE✅ 原子，但物理目录删除延迟到 post-DDL 阶段；崩溃后data/mydb/可能还在，而INFORMATION_SCHEMA.SCHEMATA已不可见 - 跨库
RENAME TABLE❌ 不支持原子——因涉及多个库的字典表，无法打包进单事务
失败不等于没做，ERROR 1033/1286/1872 往往是底层状态撕裂
原子 DDL 在准备阶段就校验一致性，一旦发现字典与物理文件错位，会直接拒绝执行并报错，而不是硬着头皮改到一半。典型表现：
-
ERROR 1033 (HY000): Incorrect information in file './db/t1.frm'：实际是.ibd文件头的space_id与INFORMATION_SCHEMA.INNODB_SYS_TABLES记录不匹配 -
ERROR 1286 (42000): Unknown storage engine 'innodb'：常因mysql.innodb_table_stats表损坏，导致 Server 层无法确认引擎状态 -
ERROR 1872 (HY000): Cannot truncate a table referenced in a foreign key constraint：多因INFORMATION_SCHEMA.INNODB_FOREIGN缓存未刷新，而非真实外键冲突
这类错误背后不是语法问题，而是 INFORMATION_SCHEMA.INNODB_SYS_TABLES 有记录但磁盘上 .ibd 缺失，或反之。修复前务必先用 SELECT NAME, SPACE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME = 'db/t1' 和 ls -l /var/lib/mysql/db/t1.ibd 交叉验证，否则盲目操作可能扩大不一致范围。
