为什么MySQL 8.0的原子DDL操作对运维更友好？

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 流程：

1. 物理文件操作（重命名、删除 .ibd）被推迟到 post-ddl 阶段，仅在数据字典事务提交后才执行
2. 崩溃重启后，InnoDB 自动回滚未完成的字典事务，mysql.innodb_ddl_log 中残留日志会被重放并清理
3. 你永远只看到完整旧结构或完整新结构，绝不会出现“新加了列但索引丢了”或“字段类型改了一半”

MDL 锁持有时间大幅缩短

老版本 ALTER TABLE 一上来就抢 MDL_EXCLUSIVE 锁，全程阻塞所有读写；8.0 原子 DDL 把锁拆成多阶段：

1. 解析与校验阶段：只持 MDL_SHARED_READ 或 MDL_SHARED_WRITE，允许并发查询
2. 准备阶段（如建临时表、重写行）：短暂升级为 MDL_EXCLUSIVE，但只在真正更新字典前几毫秒
3. 提交阶段：一次性刷完字典变更并释放所有 MDL 锁

结果就是：一个耗时 5 分钟的大表加列，对线上业务的阻塞窗口可能只剩最后 200ms，而不是全程卡死。

Binlog 与实际元数据严格对齐

以前主库 DROP TABLE t 写了 binlog，但从库回放时报 Table t doesn't exist，常见原因就是主库 DDL 执行到一半崩溃，binlog 记了但字典没改完。

原子 DDL 把“更新字典 + 写 binlog + 修改存储引擎”三者绑进同一个内部事务：

1. binlog 中记录的 DDL 事件，必定对应一个已完全生效的元数据状态
2. 从库回放时，不需要猜测“这一步到底成没成”，因为主库上它要么全提交、要么全丢弃
3. 注意：binlog_format=STATEMENT 下函数/变量仍可能导致不一致，但 DDL 本身的原子性不受影响；推荐用 ROW 或 MIXED

哪些 DDL 真正受保护，哪些只是幻觉

原子性不是对所有 DDL 生效。必须同时满足两个条件：

1. 语句本身在最新文档中标注为 Atomic DDL supported: Yes
2. 操作对象是 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，而不是悄悄降级为非原子流程。