MySQL 8.0中ALTER TABLE、DROP TABLE等DDL操作仅对InnoDB表支持原子性，因其依赖InnoDB事务机制和集中式事务性数据字典；MyISAM等非事务引擎表执行DDL仍会部分成功且无法回滚。
ALTER TABLE、DROP TABLE 这类操作在 MySQL 8.0 中能原子执行，前提是表必须用 InnoDB 引擎。不是版本够新就行，而是底层机制决定了它只能跑在 InnoDB 上。
原子 DDL 的核心依赖是事务性数据字典
MySQL 8.0 把所有元数据（表结构、列、索引、外键等）全搬进了mysql.tables、mysql.columns 等系统表——而这些系统表本身就是 InnoDB 表。
这意味着：
- 每次 ALTER TABLE 实际上是一组对这些系统表的 INSERT/UPDATE/DELETE 操作
- 这些操作被包裹在一个隐式 InnoDB 事务里，受 ACID 约束
- 崩溃时靠 InnoDB 的 redo/undo 日志回滚，确保字典状态一致
如果换成 MyISAM 或 MEMORY，它们没有事务能力，无法保证对系统表的写入可回滚，原子性就断在第一步。
非 InnoDB 表执行 DDL 会直接报错
你不需要等到执行完才发现问题，MySQL 在解析阶段就会拦截： - 执行ALTER TABLE t ENGINE=MyISAM 后再跑 ALTER TABLE t ADD COLUMN x INT，会立刻报：
ERROR 1235 (42000): This version of MySQL doesn't yet support 'ALTER TABLE' for this storage engine
- SHOW CREATE TABLE t 输出里没看到 ENGINE=InnoDB，就别指望原子性
- 即使 mysql.innodb_ddl_log 表存在，它也只记录 InnoDB 表的 DDL 日志，对 MyISAM 完全不生效
检查和转换必须手动做，且有风险
- 查引擎：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t';
- 转换命令本身是原子的（只要原表是 InnoDB），但：
- ALTER TABLE t ENGINE=InnoDB 会锁全表，线上业务需评估停写时间
- 若原表有外键或大字段（如 TEXT、BLOB），转换可能触发临时空间暴涨
- 不支持 ALGORITHM=INPLACE 的老版本 MySQL，转换过程更重
mysql 系统库本身不受影响，但业务表必须自己管
mysql.user、mysql.db 这些系统表在 8.0 中全是 InnoDB，所以 CREATE USER、GRANT 天然原子。
但你的业务表不会自动继承这个特性——哪怕建在同一个实例里，引擎不是 InnoDB，就等于站在原子 DDL 的防火墙外面。
真正容易被忽略的点是：原子性不是“开个开关就能有”，而是由存储引擎决定的硬约束。哪怕你用的是 MySQL 8.0.30，只要表引擎不是 InnoDB，DDL 就退化回 5.7 那套非原子逻辑。
