MySQL 8.0原子DDL通过将元数据统一存入InnoDB系统表（如mysql.tables、mysql.columns），并绑定字典更新、引擎操作与binlog写入为单事务，确保崩溃后自动回滚，杜绝“半改不改”残血表；而5.7因.frm文件、InnoDB字典、binlog三步分离且无事务兜底，宕机易致元数据撕裂、查询报错、主从错位。
MySQL 8.0 的原子 DDL 不是让 DDL “看起来更稳”，而是让崩溃后数据库还能正常启动、查询、复制——否则你可能面对一个 Table definition has changed, please retry transaction 报错却无法修复的表。
为什么 MySQL 5.7 的 ALTER TABLE 崩溃后会卡死
老版本执行 ALTER TABLE 实际分三步独立操作：改 .frm 文件 → 更新 InnoDB 内部字典 → 写 binlog。任意一步中断，状态就撕裂：
- InnoDB 认为新增了一列（内部字典已更新），但客户端读
.frm还是旧结构，直接报错无法 SELECT - binlog 没记这条 DDL，从库跳过或卡住，元数据永久错位
- 磁盘上残留
#sql-xxxxx.ibd临时文件，DBA 得手动解析、rename、清缓存，稍有不慎就丢数据
MySQL 8.0 原子 DDL 怎么用事务兜底
它把所有元数据（表、列、索引定义）全搬到 mysql.tables、mysql.columns 等 InnoDB 系统表里，DDL 变成标准事务：
-
ALTER TABLE t ADD COLUMN c INT会同时向mysql.columns插入行、更新mysql.tables.se_private_data、写入mysql.innodb_ddl_log（物理回滚日志） - 这些操作和业务事务一样走 undo log + redo log，崩溃重启后由 InnoDB 自动回滚整个事务
- 你查
SHOW CREATE TABLE t，永远只看到完整旧结构或完整新结构，没有中间态
哪些 DDL 真正受原子性保护
不是所有语句都进事务队列。关键看是否操作 InnoDB 表或其元数据：
- ✅ 支持：对 InnoDB 表的
CREATE/DROP/ALTER、TRUNCATE TABLE、CREATE OR REPLACE VIEW - ❌ 不支持：
INSTALL PLUGIN、ANALYZE TABLE（不改元数据）、CREATE SERVER - ⚠️ 注意：
DROP DATABASE是原子的，但物理目录删除延迟到 post-DDL 阶段——崩溃重启后data/mydb/可能还在，但INFORMATION_SCHEMA.SCHEMATA已查不到，后续自动清理
容易被忽略的隐性依赖点
原子 DDL 能生效，前提是整个链路没被绕过：
- 必须用 InnoDB 引擎——MyISAM 或 Memory 表不参与这套机制
-
binlog_format必须为ROW或MIXED，否则 DDL 事件无法作为事务一部分写入 - 不要禁用
innodb_force_recovery以外的崩溃恢复开关；若手动删了mysql.ibd或清空系统表空间，原子性保障直接失效
