mysql 5.7 ddl 不可回滚因元数据分散于.frm/.trg/.opt文件及myisam系统表，无统一事务锚点；8.0通过将元数据全存入innodb事务表实现原子ddl，但仅限innodb等事务引擎对象。
MySQL 5.7 的 DDL 操作无法回滚，不是设计疏漏，而是架构决定的——它根本就没有统一的事务锚点；MySQL 8.0 能原子 DDL，是因为把所有元数据都塞进了 InnoDB 表里，让 DDL 变成了标准事务。
MySQL 5.7 的元数据散落在哪？
5.7 的表结构、触发器、数据库选项这些信息，不是存在一张表里，而是拆成好几处：
-
.frm文件存表定义，.TRG存触发器，.OPT存库选项，全在文件系统里，不参与事务 -
mysql.tables等系统表用的是MyISAM引擎，不支持ROLLBACK - InnoDB 自己还维护一份内部字典（比如
dict_table_t），和 Server 层的.frm不同步
执行 DROP TABLE t1, t2 时，Server 层删 t1.frm → 删 t2.frm → 通知 InnoDB 清理空间。中间 crash，t1 的文件和字典可能已删，t2 还原封不动，mysql.tables 里记录也可能只删了一半。
MySQL 8.0 的数据字典怎么做到事务化？
8.0 把所有元数据统一收进 InnoDB 系统表：mysql.tables、mysql.columns、mysql.triggers 全是事务型表，DDL 就变成对这些表的增删改 + 用户表物理变更，全部包在一个事务里。
- 执行
ALTER TABLE t ADD COLUMN c INT，实际是：INSERT INTO mysql.columns+UPDATE mysql.tables+ 扩展数据页，全部在同一个START TRANSACTION ... COMMIT中 - 崩溃时靠 InnoDB 的
redo/undo自动回滚整个事务，mysql.tables和用户表数据状态一致 -
mysql.innodb_ddl_log是隐藏日志表，记录“重命名文件 X 为 Y”这类需延迟执行的操作，只在post-ddl阶段真正落盘
哪些 DDL 在 8.0 真正原子？哪些只是“看起来像”？
原子性只对走新字典路径、且引擎支持事务的对象生效：
- ✅ 支持原子：所有
InnoDB表的CREATE/DROP/ALTER、RENAME TABLE t1 TO t2, t3 TO t4、TRUNCATE TABLE、视图/存储过程/触发器/用户/角色等 - ❌ 不保证原子：涉及
MyISAM、CSV等非事务引擎的表；ALGORITHM=COPY被 kill 后残留的临时表（如#sql-*）；调用 UDF 或写磁盘的插件逻辑
升级后如果发现某条 ALTER TABLE 仍留临时文件，先查 SELECT ENGINE FROM information_schema.tables WHERE TABLE_NAME = 't'，确认是不是用了非 InnoDB 引擎。
升级后为什么有时“感觉不到原子性”？
不是机制失效，而是边界条件没覆盖到：
- 开启
old_mode=NO_TABLE_OPTIONS会绕过新字典路径，退化为 5.7 式操作 -
innodb_print_ddl_logs=1没开，就看不到mysql.innodb_ddl_log的重放过程，误以为没回滚 - DDL 语句里混了
IF NOT EXISTS或IF EXISTS，失败部分不报错但也不计入事务，容易误判成功范围
最常被忽略的是：一旦在 8.0 实例中执行过任意 DDL，mysql 库的表结构就可能被升级写入新字段，此时再用 5.7 的 mysqld 启动该 datadir，直接拒绝启动——这不是 bug，是数据字典格式不可逆的硬限制。
