MySQL 8.0原子DDL是防止元数据崩坏的最后一道事务防线，它将元数据统一存入InnoDB系统表，使DDL操作（如ALTER TABLE）成为ACID事务：任一环节崩溃，重启后自动回滚，杜绝“半改不改”的残血表状态。
MySQL 8.0 的原子 DDL 不是“更稳一点”的可选项，而是防止元数据崩坏的最后一道事务防线——它直接决定一次 ALTER TABLE 崩溃后，你面对的是自动恢复的干净状态，还是必须停服、导出、重建的“残血表”现场。
MySQL 5.7 及之前 DDL 崩溃后为什么留坑？
老版本的 DDL 实际是三段裸奔操作：.frm 文件改了 → InnoDB 内部字典更新了 → binlog 才写。这三步彼此无事务约束：
- 断电发生在第二步之后、第三步之前？
SHOW CREATE TABLE会报Table definition has changed, please retry transaction，但表既不能读也不能修 -
DROP TABLE t1, t2中t2不存在？t1被删光，t2报错退出，没有回滚机制兜底 - 从库复制时发现
binlog缺失该 DDL 记录，可能跳过或卡死，元数据永久错位
MySQL 8.0 原子 DDL 怎么做到崩溃后自动清理？
核心是把所有元数据（表结构、列、索引、用户等）全搬进 InnoDB 系统表，比如 mysql.tables、mysql.columns，和业务数据一样受 ACID 约束。一次 ALTER TABLE 就是一个标准 InnoDB 事务：
- 所有字典表变更（如向
mysql.columns插入新列）在同一个事务内完成 - InnoDB 引擎层同步更新内存对象（如
dict_table_t） -
binlog事件也作为该事务的一部分写入，不再单独提交 - 崩溃重启后，InnoDB 崩溃恢复机制直接回滚整个事务——就像没执行过
你查 SHOW CREATE TABLE，永远只看到完整旧结构或完整新结构，绝不会出现“新加了一列但索引丢了”的中间态。
哪些 DDL 语句真正受原子性保护？
不是所有 DDL 都能原子化。关键看两点：是否涉及表、以及存储引擎是否支持：
- ✅ 支持原子性的表相关 DDL：
CREATE TABLE、ALTER TABLE、DROP TABLE、TRUNCATE TABLE—— 仅限InnoDB表 - ✅ 非表类 DDL 全支持：
CREATE USER、DROP ROLE、CREATE VIEW、GRANT/REVOKE - ❌ 明确不支持：
MyISAM、Memory等非事务引擎的表操作；RENAME TABLE跨库操作（因涉及多库元数据）
执行前务必确认表引擎：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t';
原子 DDL 默认开启，但有隐藏依赖
它不需要手动开关，但隐含两个硬性前提：
- MySQL 必须运行在
innodb_force_recovery=0模式下（即正常模式），否则原子事务无法启动 -
mysql.innodb_ddl_log表必须可写（它藏在mysql.ibd里），若磁盘满或权限异常，DDL 会直接失败并报错ER_DDL_LOG_ERROR - 虽然 DDL 自动事务化，但它仍会加
MDL（元数据锁），高并发场景下ALTER TABLE仍可能阻塞后续查询——原子性 ≠ 无锁
最容易被忽略的是：原子 DDL 保的是元数据一致性，不保数据行级一致性。比如 ADD COLUMN 后立即插入新列值，该插入本身仍是普通 DML，需自行保证事务边界。
