mysql 8.0原子ddl指ddl自身操作的原子性，即元数据变更、存储引擎改动和binlog写入绑定为不可分割单元，而非支持在begin/commit中执行ddl；它依赖事务性数据字典和ddl log实现崩溃安全，但会隐式提交并禁止嵌套于显式事务。
原子DDL不是“事务里能执行DDL”的意思
很多人看到“原子”就下意识联想到 BEGIN/COMMIT，但 MySQL 8.0 的原子 DDL 并不意味着你可以在一个显式事务里执行 ALTER TABLE 或 DROP VIEW。它指的是 DDL 自身内部操作的原子性：元数据变更、存储引擎层改动、binlog 写入这三者被绑定为一个不可分割的单元。哪怕服务器在 ALTER TABLE 执行中途宕机，重启后也不会留下“表结构改了一半”或“字典记录已删但.ibd 文件还在”的残缺状态。
这种原子性靠的是事务性数据字典（InnoDB 表空间里的 mysql.* 系统表）和 DDL Log（写在系统表空间中的日志记录）协同完成，而不是复用用户事务的 ACID 机制。
MDL 锁行为变化：更短持有期 + 更早释放
MySQL 5.7 及以前，ALTER TABLE 会在整个过程中长期持有 MDL_EXCLUSIVE 锁，阻塞所有读写；而 8.0 原子 DDL 将锁拆成多个阶段：
- 解析与校验阶段：只持
MDL_SHARED_READ或MDL_SHARED_WRITE，允许并发查询 - 准备阶段（如创建临时表、重写行数据）：升级为
MDL_EXCLUSIVE，但仅在真正修改数据字典前短暂持有 - 提交阶段：一次性更新数据字典并释放所有 MDL 锁
这意味着长耗时 DDL（比如大表加列）对线上业务的阻塞窗口明显缩短——锁主要卡在最后那几百毫秒，而不是全程数分钟。
为什么不能在事务中嵌套 DDL？
MySQL 明确禁止在显式事务中执行大多数 DDL 语句，报错是：ERROR 1785 (HY000): Statement violates GTID consistency: CREATE TABLE ... is not allowed in transactions（即使关了 GTID，也会报 ERROR 1305 (42000): SAVEPOINT does not exist 类似错误）。
原因很直接：
- DDL 操作本身会隐式触发
COMMIT（无论是否在事务块内） - 事务性数据字典的提交逻辑和用户事务隔离层不兼容，无法共享 undo log 或事务 ID
-
CREATE OR REPLACE VIEW是原子操作，但它仍是独立的 DDL 单元，不能回滚到上一个SAVEPOINT
所以别试图用 START TRANSACTION 包住 ALTER 来“控制回滚点”——它根本不会按你想的方式工作。
真正影响事务一致性的场景：DDL 与长事务共存
最常被忽略的坑是：正在运行的长事务（比如一个跑了 10 分钟的 SELECT ... FOR UPDATE）会让 DDL 卡在等待 MDL 锁的阶段，反过来又导致后续所有 DML 被阻塞。这是因为 DDL 需要获取 MDL_EXCLUSIVE，而长事务持有的 MDL_SHARED_WRITE 不会主动释放。
排查方法：
- 查
performance_schema.metadata_locks，看OBJECT_TYPE = 'TABLE'且LOCK_STATUS = 'PENDING'的记录 - 结合
information_schema.INNODB_TRX找出TRX_STARTED时间早于 DDL 请求时间的事务 - 注意：DDL 等待锁超时默认是
lock_wait_timeout（通常 31536000 秒），几乎等于永久等待
这类问题不会因为“用了原子 DDL”就消失；它只是让 DDL 自身更健壮，但没解决锁资源竞争的本质。
