MySQL 8.0的Atomic DDL是InnoDB表DDL的默认行为，无需配置；其原子性源于废除.frm文件，将元数据全存入InnoDB系统表并依赖事务、redo log与innodb_ddl_log保障崩溃一致性。
MySQL 8.0 的 Atomic DDL 不是“保证元数据变更原子性”的可选机制，而是 InnoDB 表 DDL 的默认行为——你不需要做任何配置，只要用的是 InnoDB（默认引擎），CREATE TABLE、ALTER TABLE、DROP TABLE 等操作天然就是原子的。
为什么以前的 DDL 不原子？关键在 .frm 文件和字典分离
MySQL 5.7 及之前，表结构存在 .frm 文件里，而 InnoDB 自己维护一套内存+系统表空间里的字典。执行 ALTER TABLE 时：先改 .frm，再更新 InnoDB 字典，最后重命名文件——三步独立，崩溃可能卡在任意中间状态。比如字典已更新但 .frm 没写完，重启后 MySQL 读 .frm 和字典对不上，报错 Table definition has changed, please retry transaction，表直接不可用。
Atomic DDL 的根本解法是：彻底废掉 .frm，把所有元数据（表、列、索引定义等）全存进 InnoDB 引擎的系统表（如 mysql.tables、mysql.columns），和业务表一样走 ACID 流程。
Atomic DDL 实际执行分四阶段，innodb_ddl_log 是回滚关键
DDL 不是简单一个事务提交就完事。它拆成准备 → 执行 → 提交 → post-ddl 四步，其中物理文件操作（如删 .ibd、重命名）全部推迟到 post-ddl 阶段，且只在数据字典事务成功提交后才触发。
- 崩溃发生在“执行”或“提交”阶段？InnoDB 崩溃恢复会回滚整个字典事务，
innodb_ddl_log表里记录的待清理动作（如“删除旧.ibd”）会被重放并清除，磁盘不留残迹 - 崩溃发生在
post-ddl阶段？日志已清，但物理文件可能没删干净——这时innodb_ddl_log已空，需人工检查残留（极少见，通常只发生在极端异常中断） -
innodb_ddl_log是隐藏表，位于mysql.ibd内，不可查不可删；想看内容得开 debug 模式：SET SESSION debug='+d,skip_dd_table_access_check'，再SHOW CREATE TABLE mysql.innodb_ddl_log
哪些 DDL 真的不原子？别踩非 InnoDB 引擎和冷门语句的坑
Atomic DDL 仅对 InnoDB 表生效。一旦涉及其他引擎，MySQL 直接报错：
ERROR 1235 (42000): This version of MySQL doesn't yet support 'ALTER TABLE' for this storage engine
同样不支持原子性的还有：
-
INSTALL PLUGIN、UNINSTALL PLUGIN -
INSTALL COMPONENT、UNINSTALL COMPONENT -
CREATE SERVER、DROP SERVER - 任何对 MyISAM、MEMORY、CSV 表的
DROP/ALTER
注意：CREATE USER、GRANT、CREATE VIEW 这些虽不操作表，但底层改的是 mysql 库下的 InnoDB 系统表，所以天然受 Atomic DDL 保护。
binlog 与实际状态对齐，但别忽略 binlog_format 的影响
Atomic DDL 把“更新字典 + 写 binlog + 修改引擎”绑进同一内部事务，所以主库 DROP TABLE t 要么全提交（binlog 有记录，从库能执行），要么全丢弃（binlog 无记录，从库跳过）。这解决了 MySQL 5.7 常见的“主库删了表，从库报 Table doesn't exist”问题。
但有个易忽略点：binlog_format=STATEMENT 下，若 DDL 语句里含非确定性函数（如 NOW()、UUID()），仍可能导致主从不一致——DDL 原子性本身不受影响，但 binlog 回放结果可能偏离预期。生产环境务必用 ROW 或 MIXED。
真正难调试的不是“原子性是否生效”，而是当操作跨多个对象（如 DROP TABLE t1, t2, t3）时，错误是否被正确隔离——MySQL 8.0 会整体失败，不会出现只删掉其中两个的情况；但如果你混用了 InnoDB 和 MyISAM 表，报错位置可能不直观，得逐个确认引擎类型。
