Atomic DDL是MySQL 8.0中InnoDB表DDL的默认行为，CREATE/ALTER/DROP/TRUNCATE等操作天然原子，崩溃后无残留文件、binlog与状态严格一致，且仅支持InnoDB引擎。
Atomic DDL 不是“建议使用”的可选项，而是 MySQL 8.0 中 InnoDB 表 DDL 的默认行为——只要你用的是默认引擎，CREATE TABLE、ALTER TABLE、DROP TABLE、TRUNCATE TABLE 这些操作天然就是原子的，无需配置、无需包裹事务、也不存在“开启开关”这回事。
真正影响运维效率的，是它消除了过去必须人工介入的几类典型故障场景。
DDL 崩溃后不再需要手动清理残留文件
MySQL 5.7 执行 ALTER TABLE 时，会在数据目录下生成类似 #sql-ib12345.ibd 或 #sql-abc.frm 的临时文件。一旦进程被 kill -9 或断电中断，这些文件就卡在那里，既不能删也不能用，DBA 得靠经验判断是否安全清理。
MySQL 8.0 的 Atomic DDL 把物理文件操作（重命名、删除 .ibd）推迟到 post-ddl 阶段，且仅在数据字典事务成功提交后才执行。崩溃重启后，mysql.innodb_ddl_log 表里的记录会被自动重放或回滚，磁盘上不会留下任何中间态文件。
常见错误现象：
- ERROR 1050 (42S01): Table 't1' already exists（其实只是残留了未清理的临时表名）
- Table definition has changed, please retry transaction（元数据与 .frm 不一致）
这些在 8.0 中基本消失。
主从复制中 DDL 状态与 binlog 严格对齐
老版本 DDL 写 binlog 是独立于元数据变更的，容易出现“binlog 记了 DROP TABLE t，但从库执行时报 Table t doesn't exist”，因为主库实际只改了一半字典或没写完日志。
8.0 把“更新数据字典 + 写 binlog + 修改 InnoDB 引擎层结构”三者绑进同一个内部事务。这意味着：
-
binlog里出现的 DDL 事件，必定对应一个已完全生效的元数据状态 - 从库回放时，不会遇到“该表存在但结构不匹配”或“该表已被删却还在被引用”的错乱状态
- 即使
binlog_format=STATEMENT，DDL 本身的原子性也不受影响（但函数/变量相关语句仍需注意）
非 InnoDB 表执行 DDL 会直接报错，而不是静默失败
如果你的表是 MyISAM 或 MEMORY 引擎，执行 ALTER TABLE 会立刻失败：
ERROR 1235 (42000): This version of MySQL doesn't yet support 'ALTER TABLE' for this storage engine
这不是 bug，是设计使然：只有 InnoDB 能保证数据字典变更可回滚，mysql.tables、mysql.columns 等系统表本身也是 InnoDB 表，非事务引擎无法参与原子流程。运维人员看到这个错误，就必须先 ALTER TABLE ... ENGINE=InnoDB，而不是等崩溃后才发现元数据崩坏。
检查方法很简单：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='your_table';
原子 DDL 依赖两个隐藏前提，容易被忽略
它默认开启，但不是无条件生效：
-
innodb_force_recovery必须为0（即正常运行模式），否则原子事务无法启动 -
mysql.innodb_ddl_log表必须可写——它藏在mysql.ibd里，如果磁盘满、权限异常或mysql库被误删，DDL 会直接失败并报ER_DDL_LOG_ERROR
这类问题不会在日常 DDL 中暴露，往往只在磁盘空间告警后或权限变更后突然触发，且错误信息不直观，容易误判为语法或锁表问题。
