MySQL 8.0原子DDL禁止在START TRANSACTION中执行ALTER TABLE等DDL语句，因其会隐式触发COMMIT、不共享用户事务的undo log和隔离视图，且报错ERROR 1785或1305；它仅保障单条DDL内部元数据、存储引擎和binlog操作的崩溃安全原子性，而非支持事务嵌套。
MySQL 8.0 的原子 DDL 不让你在事务里执行 DDL，但它让单条 DDL 自身更安全、锁得更短。
为什么不能在 START TRANSACTION 里写 ALTER TABLE？
这不是配置问题，是 MySQL 明确禁止的。你一写就会报错：
ERROR 1785 (HY000): Statement violates GTID consistency- 或者关了 GTID 后：
ERROR 1305 (42000): SAVEPOINT does not exist
原因很直接：所有 DDL 语句（CREATE、ALTER、DROP 等）都会隐式触发 COMMIT，不管它是不是包在 BEGIN 里。它不共享用户事务的 undo log，也不走同一套隔离视图。所以别试图用事务来“回滚一个加字段操作”——根本不会生效。
MDL 锁持有时间大幅缩短，但长事务仍会卡住 DDL
老版本 ALTER TABLE 一上来就抢 MDL_EXCLUSIVE 锁，全程阻塞读写；8.0 把锁拆成多阶段：
- 解析与校验阶段：只持
MDL_SHARED_READ或MDL_SHARED_WRITE，允许并发查询 - 准备阶段（如建临时表）：短暂升级为
MDL_EXCLUSIVE，仅持续几毫秒 - 提交阶段：一次性刷完字典变更并释放所有 MDL 锁
结果是：一个耗时 5 分钟的加列操作，业务被阻塞的时间可能只剩最后 200ms。但要注意——如果此时有个跑了 10 分钟的 SELECT ... FOR UPDATE 正在执行，DDL 会一直卡在等待 MDL 锁，反过来又堵住后续所有 DML。这个坑比锁时间本身更常被忽略。
哪些 DDL 真的不原子？别踩引擎和语句的边界
原子 DDL 只对 InnoDB 表生效。一旦涉及其他引擎，MySQL 直接报错：
ERROR 1235 (42000): This version of MySQL doesn't yet support 'ALTER TABLE' for this storage engine- 非 InnoDB 表（如
MyISAM、Memory）上的ALTER、DROP全都不原子 -
INSTALL PLUGIN、CREATE SERVER、TRUNCATE TABLE（注意：虽然文档说支持，但实际行为依赖引擎实现，TRUNCATE在非 InnoDB 上仍不保证原子）
另外，CREATE OR REPLACE VIEW 是原子的，但它仍是独立 DDL 单元，不能回滚到上一个 SAVEPOINT —— 它只管自己这一条语句的成败。
真正容易被忽略的点在于：原子性保障的是单条 DDL 内部操作的崩溃一致性（比如字典+ibd+binlog 三者同步成功或全部回滚），而不是让你“控制 DDL 的事务边界”。运维友好，不等于开发自由。
