mysql 8.0 原子ddl确保单条ddl操作“全有或全无”，通过将元数据存入innodb系统表、绑定字典更新/引擎变更/binlog写入为一个隐式事务，并依赖崩溃恢复与ddl_log表保障文件操作原子性。
MySQL 8.0 的原子 DDL 不是“让你把多个 ALTER 包进事务”，而是确保单条 DDL 自身执行失败时不会留下半改不改的残血状态——这是它最核心、也最容易被误解的安全保障。
为什么 START TRANSACTION + ALTER TABLE 会报错 ERROR 1785
MySQL 明确禁止在用户事务中执行 DDL。所有 DDL（包括 ALTER TABLE）都会隐式触发 COMMIT，并清空当前事务上下文。一旦你在 START TRANSACTION 后写 ALTER TABLE，就会立刻收到：ERROR 1785 (HY000): Statement violates GTID consistency 或 ERROR 1305 (42000): SAVEPOINT does not exist。
这不是配置没开、权限不够，也不是版本太低——这是 MySQL 8.0 的硬性设计：DDL 内部自有事务边界，不接受外部包裹。
- 原子性只作用于单条 DDL 的内部流程（元数据更新 + 引擎变更 + binlog 写入）
-
START TRANSACTION只对 DML 有效；混入 DDL 就等于主动破坏事务一致性 - 想批量执行多条 DDL？必须用 MySQL 8.0.23+，且全部语句都得是官方标注
Atomic DDL supported: Yes的操作
哪些 ALTER TABLE 真正受原子性保护
不是语法能跑通就等于安全。MySQL 8.0 原子 DDL 支持范围极窄，只覆盖部分轻量级结构变更：
- 支持原子性：
ADD COLUMN（末尾添加、不触发COPY）、DROP COLUMN（非全文索引列）、ADD INDEX/DROP INDEX（不含FULLTEXT）、RENAME TABLE（同库）、ALTER TABLE ... ENGINE=InnoDB - 明确不支持：
MODIFY COLUMN、CHANGE COLUMN、OPTIMIZE TABLE、跨库RENAME TABLE——这些失败后可能已改元数据但未刷 binlog，无法整体回滚 - 查文档确认：执行前务必核对 MySQL 官方手册中对应语句的 “Atomic DDL supported” 标注栏
崩溃后怎么验证原子性生效了
别信错误日志，要看重启后的实际状态。服务器异常中断后，用这两条命令交叉比对：
- 运行
SHOW CREATE TABLE t1：结果只能是“完整旧结构”或“完整新结构”，绝不会出现“有新列但缺索引”或“索引名变了但列没加” - 查
SELECT * FROM information_schema.INNODB_TABLES WHERE NAME LIKE 'db/t1'：看TABLE_SCHEMA和TABLE_NAME是否一致，版本号是否跳变 - 注意：
mysql.innodb_ddl_log是隐藏系统表，普通账号查不到，也不该手动干预——它是 InnoDB 内部回滚凭证，不是给 DBA 看的日志
真正容易被忽略的是：原子 DDL 只管“改完或不改”，不管“能不能改”。哪怕语句本身支持原子性，若执行时遇上长事务占着 MDL 锁、磁盘满、内存不足，照样失败——它不解决阻塞问题，只解决失败后的状态残留问题。
