mysql 5.7的ddl无法回滚，因其元数据散落在.frm等文件中且由myisam管理，不支持事务；而8.0将元数据统一存入innodb系统表并依赖innodb_ddl_log实现原子性。
MySQL 5.7 的 DDL 操作为什么无法回滚
因为它的数据字典元数据仍散落在文件系统中（.frm、.TRG、db.opt 等），且由非事务引擎 MyISAM 管理，不支持 COMMIT/ROLLBACK。一旦 DDL 执行中途崩溃，比如 DROP TABLE t1, t2 只删了一半，就会留下 t1 丢失、t2 还在的“半成品状态”——没有统一事务锚点，数据库自己也救不回来。
常见错误现象包括：
- 执行
ALTER TABLE时 mysqld crash，重启后表结构错乱或Table 'xxx' doesn't exist -
CREATE TABLE失败但.frm文件残留，后续再建同名表报错ERROR 1050 (42S01) - 触发器定义写入
.TRG成功，但数据字典表（如mysql.triggers）未更新，导致SHOW TRIGGERS不显示
MySQL 8.0 原子DDL依赖的数据字典结构变化
所有元数据（表、列、索引、触发器、事件等）全部存进 mysql 库下的 InnoDB 表里，比如 mysql.tables、mysql.columns、mysql.triggers。这些表本身可事务化，配合 mysql.innodb_ddl_log（隐藏表，位于 mysql.ibd 内）记录前滚/回滚步骤，才让原子性成为可能。
关键差异点：
-
.frm等文件已彻底移除，不再有“文件 vs 表”双源不一致风险 -
mysql系统库全为 InnoDB 引擎，崩溃恢复时能通过 redo/undo 保证字典一致性 - 每个 DDL 操作会先写
mysql.innodb_ddl_log记录（如DELETE SPACE、REMOVE CACHE），失败时靠它回退物理操作 - 必须开启
innodb_print_ddl_logs=1才能在 error log 看到 DDL 日志重放过程
回滚行为的实际表现对比
执行 DROP TABLE t1, t2 时：
- MySQL 5.7：若在删
t1后崩溃，t2仍在，t1的.frm和.ibd可能残留，需人工清理并修复mysql.tables（高危） - MySQL 8.0：整个语句作为一个事务提交；崩溃后重启，InnoDB 自动回滚该事务，
t1和t2都完好无损，mysql.tables无变更，mysql.innodb_ddl_log中的记录也被清除
注意：mysql.innodb_ddl_log 是隐藏系统表，普通用户无法 SELECT，也不能手动修改——它只供 InnoDB 内部使用。
升级后不可逆的关键限制
MySQL 8.0 的原子 DDL 能力不是“开关”，而是深度绑定新数据字典格式。这意味着：
- 一旦在 8.0 实例中执行过任意 DDL（哪怕只是
ALTER TABLE ... COMMENT），mysql库的 InnoDB 表结构就可能被升级写入新字段 - 此时用 5.7 的
mysqld直接启动该datadir，会报错Table mysql.tables has unknown column type或直接拒绝启动 - 官方明确不支持 8.0 → 5.7 降级；唯一安全回退路径是升级前做的逻辑备份（含
--routines --events --triggers --single-transaction）并在干净的 5.7 实例中导入
最容易被忽略的是：即使没执行业务 DDL，只要运行过 mysqld --upgrade 或首次以 8.0 启动带旧数据的实例，数据字典就已静默升级——这时再想回退，只剩备份还原一条路。
