MySQL 8.0原子DDL确保ALTER TABLE崩溃后无“半改不改”表，因其将元数据更新、引擎修改与binlog写入打包进单个InnoDB隐式事务，崩溃时由redo/undo自动回滚；而5.7因.frm文件、引擎字典、binlog三者分离且无事务兜底，宕机易致元数据不一致。
ALTER TABLE 崩溃后不会留下“半改不改”的表，不是因为 MySQL 变得更聪明了，而是它把所有元数据操作塞进了一个真正的 InnoDB 事务里——崩溃时直接回滚，就像没执行过。
原子DDL不是让DDL支持BEGIN/COMMIT，而是让它自带崩溃安全
MySQL 8.0 的 ALTER TABLE 看似一条语句，底层其实是：向 mysql.columns 插入新列记录、更新 mysql.tables 中的版本号、同步修改 dict_table_t 内存对象、写入 binlog 事件——全部打包在一个隐式事务中。这个事务走标准 redo/undo 流程，和你的 UPDATE 无异。
所以杀掉 mysqld 进程再重启，InnoDB 崩溃恢复机制会自动识别该事务未提交，直接丢弃所有变更。你查 SHOW CREATE TABLE，永远只看到旧结构或新结构，绝不会出现“新加了一列但索引丢了”或者“Table definition has changed, please retry transaction”这种报错。
为什么老版本的DDL一崩就残血？
MySQL 5.7 及之前，ALTER TABLE 是三段裸奔：
- 改
.frm文件（文件系统操作，无事务） - 更新 InnoDB 内部字典（事务性，但和 .frm 不联动）
- 重命名物理文件或刷 binlog（又一个独立动作）
断电发生在第二步之后、第三步之前？结果就是：InnoDB 认为表已加列，.frm 还是旧的，binlog 缺失记录。从库复制卡住，客户端 SELECT 直接失败，DBA 得手动导出重建——这不是运维，是抢救。
哪些DDL真能原子化？别被名字骗了
原子性只覆盖明确由事务性数据字典参与管理的操作，且依赖存储引擎：
-
✅ 支持：对
InnoDB表的CREATE TABLE、ALTER TABLE、DROP TABLE、TRUNCATE TABLE；还有CREATE USER、GRANT、CREATE VIEW -
❌ 不支持：
MyISAM或Memory表的任何 DDL；RENAME TABLE跨库操作；INSTALL PLUGIN；ANALYZE TABLE（它不改元数据） -
⚠️ 注意：
DROP DATABASE是原子的，但物理目录删除被延迟到 post-DDL 阶段——崩溃重启后data/mydb/可能还在，但INFORMATION_SCHEMA.SCHEMATA已查不到该库
原子DDL失败，往往不是语法问题，而是底层脱节
报 ERROR 1033、ERROR 1286 或 ERROR 1872，大概率是数据字典与物理文件对不上：
-
INFORMATION_SCHEMA.INNODB_SYS_TABLES有记录，但/var/lib/mysql/db/t1.ibd文件缺失或权限错误 -
mysql.innodb_table_stats表损坏，导致 Server 层无法确认引擎状态 - 外键约束检查失败，实则是
INFORMATION_SCHEMA.INNODB_FOREIGN缓存未刷新
修复前先跑这四条命令：SELECT NAME, SPACE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME = 'db/t1'、SELECT FILE_NAME, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME = 'db/t1'、SET GLOBAL innodb_force_recovery = 1、ls -l /var/lib/mysql/db/t1.ibd。顺序不能乱，漏掉一步就可能误判为“只能删库重导”。
innodb_force_recovery=0（即不能在强制恢复模式下运行），以及 mysql.innodb_ddl_log 表必须可写（它藏在 mysql.ibd 里）。磁盘满、权限异常、甚至 disabled_storage_engines 里禁用了 innodb，都会让原子性当场失效。 
