MySQL 8.0原子DDL仅对InnoDB表生效，因其依赖InnoDB事务机制保障元数据变更的原子性、一致性与崩溃恢复能力；MyISAM等非事务引擎表执行DDL仍会部分成功且无法回滚。
MySQL 8.0原子DDL只对InnoDB表生效
不是所有表都能享受原子性保障。如果你的表用的是 MyISAM、Memory 或其他非 InnoDB 引擎，哪怕在 8.0 环境下执行 DROP TABLE 或 ALTER TABLE，依然会部分成功、无法回滚。
检查当前表引擎的方法：
SHOW CREATE TABLE my_table;
确认输出中包含 ENGINE=InnoDB；若不是，需先转换：
ALTER TABLE my_table ENGINE = InnoDB;- 注意：该操作本身是原子的（只要原表是 InnoDB），但转换过程会锁表，线上慎用
- 批量转换时建议加
ALGORITHM=INPLACE（如果支持）减少锁时间
多语句DDL必须显式包裹在事务中
单个 ALTER TABLE 或 DROP TABLE 在 8.0 中默认就是原子的，但多个 DDL 语句之间**不自动组成一个事务**。比如你写：
DROP TABLE t1; DROP TABLE t2;
这两条仍是独立执行的——第二条失败不会让第一条回滚。
要实现“全有或全无”，必须手动开启事务：
- 用
START TRANSACTION或BEGIN显式开启 - 所有 DDL 语句放在
COMMIT前 - 任意一条失败，整个事务回滚（包括已成功执行的 DDL）
示例：
START TRANSACTION;
CREATE TABLE orders_new LIKE orders;
ALTER TABLE orders_new ADD COLUMN status ENUM('pending','done') DEFAULT 'pending';
DROP TABLE orders;
RENAME TABLE orders_new TO orders;
COMMIT;
如果 RENAME 失败（比如目标名已被占用），前面三步全部撤销，原 orders 表毫发无损。
常见误判：DROP TABLE t1, t2 并不等价于事务
很多人以为 DROP TABLE t1, t2; 是一个原子动作，其实它只是语法糖，内部仍按顺序处理每个表。虽然在 8.0 中它比 5.7 安全（错误表不会导致已有表被删），但它**不提供跨表一致性保证**。
典型陷阱场景：
-
t1存在且被删，t2不存在 → 报错，但t1已消失（这是 5.7 行为） -
t1存在，t2存在但正被其他会话使用 →t2报错，t1仍被删（8.0 改进后，t1不会被删） - 真正需要“一起删或都不删”，必须用事务 + 单独
DROP语句
正确写法：
START TRANSACTION; DROP TABLE t1; DROP TABLE t2; COMMIT;
原子DDL失败时，innodb_ddl_log 是关键线索
当原子 DDL 意外中断（如 kill 进程、断电），MySQL 重启后会自动尝试清理或回滚。底层依赖系统表 mysql.innodb_ddl_log，但它不可直接查、不可删、也不该手动干预。
排查思路只有两条：
- 看错误日志里是否有
InnoDB: DDL log entry相关记录 - 检查对应表是否还在、结构是否异常（比如
SHOW CREATE TABLE报错或字段缺失） - 若怀疑残留，可尝试
FLUSH TABLES WITH READ LOCK; UNLOCK TABLES;触发缓存刷新（非万能，仅辅助）
最稳妥的做法始终是：变更前备份 + 变更时用事务 + 关键操作后立刻验证。
别指望 innodb_ddl_log 能帮你“找回”什么——它只服务崩溃恢复，不提供用户级回退能力。
