mysql 8.0原子ddl通过将元数据统一存入innodb系统表、延迟物理文件操作至post-ddl阶段，并依托innodb_ddl_log实现崩溃自动回滚或重做，确保ddl要么全成功要么全回滚，彻底消除5.7中残留临时文件、字典与.frm不一致等“半成品”状态。
MySQL 8.0 的原子 DDL 不是“更友好一点”的优化，而是把运维从“崩溃后抢救现场”变成“重启后自动清零”的关键分水岭——它直接决定你是否需要在凌晨三点手动删 #sql-ib* 文件、修复 .frm 和 InnoDB 字典不一致，或者干脆停服重建表。
DDL 崩溃后不再留半成品表结构
MySQL 5.7 及之前版本执行 ALTER TABLE 时，会生成临时文件（如 #sql-ib12345.ibd）、改 .frm、更新内存字典、写 binlog，四步彼此无事务约束。断电卡在第三步？表就处于“能 SHOW CREATE TABLE 但 SELECT 报错”状态。
MySQL 8.0 原子 DDL 把所有元数据变更（mysql.tables、mysql.columns 等）全压进 InnoDB 系统表，和业务数据一样走 ACID 流程：
- 物理文件操作（重命名、删除
.ibd）被推迟到 post-ddl 阶段，仅在数据字典事务提交后才执行 - 崩溃重启后，InnoDB 自动回滚未完成的字典事务，
mysql.innodb_ddl_log中残留日志会被重放并清理 - 你永远只看到完整旧结构或完整新结构，绝不会出现“新加了列但索引丢了”或“字段类型改了一半”
MDL 锁持有时间大幅缩短
老版本 ALTER TABLE 一上来就抢 MDL_EXCLUSIVE 锁，全程阻塞所有读写；8.0 原子 DDL 把锁拆成多阶段：
- 解析与校验阶段：只持
MDL_SHARED_READ或MDL_SHARED_WRITE，允许并发查询 - 准备阶段（如建临时表、重写行）：短暂升级为
MDL_EXCLUSIVE，但只在真正更新字典前几毫秒 - 提交阶段：一次性刷完字典变更并释放所有 MDL 锁
结果就是：一个耗时 5 分钟的大表加列，对线上业务的阻塞窗口可能只剩最后 200ms，而不是全程卡死。
Binlog 与实际元数据严格对齐
以前主库 DROP TABLE t 写了 binlog，但从库回放时报 Table t doesn't exist，常见原因就是主库 DDL 执行到一半崩溃，binlog 记了但字典没改完。
原子 DDL 把“更新字典 + 写 binlog + 修改存储引擎”三者绑进同一个内部事务：
- binlog 中记录的 DDL 事件，必定对应一个已完全生效的元数据状态
- 从库回放时，不需要猜测“这一步到底成没成”，因为主库上它要么全提交、要么全丢弃
- 注意：
binlog_format=STATEMENT下函数/变量仍可能导致不一致，但 DDL 本身的原子性不受影响；推荐用ROW或MIXED
哪些 DDL 真正受保护，哪些只是幻觉
原子性不是对所有 DDL 生效。必须同时满足两个条件：
- 语句本身在官方文档中标注为
Atomic DDL supported: Yes - 操作对象是 InnoDB 表（
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t'）
明确支持的包括：CREATE TABLE、ALTER TABLE、DROP TABLE、TRUNCATE TABLE、CREATE USER、GRANT 等；明确不支持的包括：RENAME TABLE 跨库操作、INSTALL PLUGIN、MyISAM 表的任何 DDL —— 后者会直接报错 ERROR 1235 (42000): This version of MySQL doesn't yet support 'ALTER TABLE' for this storage engine。
最容易被忽略的是：原子 DDL 默认开启，但硬性依赖 innodb_force_recovery=0 和 mysql.innodb_ddl_log 表可写。磁盘满或权限异常时，DDL 会直接失败并报 ER_DDL_LOG_ERROR，而不是悄悄降级为非原子流程。
