mysql 8.0 的原子 ddl 是 innodb 元数据获得事务能力的分水岭，通过将元数据存入 innodb 系统表实现 acid 保障，确保 ddl 全成功或全失败，但依赖 innodb_force_recovery=0 且 mysql.ibd 可写。
MySQL 8.0 的原子 DDL 不是让 InnoDB “更好用”的优化项，而是它在元数据层面真正获得事务能力的分水岭——没有它，InnoDB 再强的数据一致性保障，也挡不住表结构改崩了。
为什么 ALTER TABLE 在 InnoDB 上曾经“改一半就卡住”
MySQL 5.7 及之前，ALTER TABLE 对 InnoDB 表实际是三段裸奔操作：.frm 文件改了 → InnoDB 内部字典（dict_table_t）更新了 → binlog 才写。这三步彼此无事务约束：
- 断电发生在第二步之后、第三步之前？
SHOW CREATE TABLE会报Table definition has changed, please retry transaction，但表既不能读也不能修 -
DROP TABLE t1, t2中t2不存在？t1被删光，t2报错退出，没有回滚机制兜底 - 从库复制时发现 binlog 缺失该 DDL 记录，可能跳过或卡死，元数据永久错位
原子 DDL 怎么让 InnoDB 元数据真正“可回滚”
核心是把所有元数据（表定义、列、索引、外键等）全搬到 InnoDB 系统表里：mysql.tables、mysql.columns、mysql.indexes……这些表本身由 InnoDB 管理，和业务表一样受 ACID 约束。
- 一次
ALTER TABLE就是一个标准 InnoDB 事务：向mysql.columns插入新列 + 更新mysql.tables+ 同步修改内存dict_table_t+ 写 binlog 事件，全部在同一个事务内完成 - 崩溃重启后，InnoDB 崩溃恢复机制直接回滚整个事务——就像没执行过
- 你查
SHOW CREATE TABLE，永远只看到完整旧结构或完整新结构，绝不会出现“新加了一列但索引丢了”的中间态
InnoDB 表才能享受原子 DDL，但不是所有 DDL 都原子
原子性依赖 InnoDB 对元数据的统一托管，所以：
- ✅ 支持原子性的表相关 DDL：
CREATE TABLE、ALTER TABLE、DROP TABLE、TRUNCATE TABLE—— 仅限ENGINE=InnoDB的表 - ✅ 非表类 DDL 全支持：
CREATE USER、GRANT、CREATE VIEW、CREATE PROCEDURE - ❌ 明确不支持：
RENAME TABLE跨库操作（涉及多库元数据）、MyISAM表的任何 DDL、INSTALL PLUGIN - 执行前务必确认引擎：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t';
原子 DDL 默认开启，但 InnoDB 有硬性前提
它不需要手动开关，但隐含两个必须满足的条件：
- MySQL 必须运行在
innodb_force_recovery=0模式下（即正常模式），否则原子事务无法启动 -
mysql.innodb_ddl_log表必须可写（它藏在mysql.ibd里），若磁盘满或权限异常，DDL 会直接失败并报错ER_DDL_LOG_ERROR - 注意：
ALTER TABLE仍会锁表（取决于 ALGORITHM），原子性 ≠ 无锁；它只保证“全成功或全失败”，不解决并发阻塞问题
真正容易被忽略的是：原子 DDL 的可靠性完全绑定在 InnoDB 自身的稳定性上——一旦 mysql.ibd 损坏或 innodb_force_recovery 被启用，原子性就失效了。这不是配置问题，而是架构级依赖。
