MySQL 5.7 的字典信息保存在非事务表中，并且存放在不同的文件中（.FRM，.PAR，.OPT，.TRN，.TRG 等)。所有 DDL 操作都不是 Crash Safe，而且对于组合 DDL（ALTER 多个表）会出现有的成功有的失败的情况，而不是总体失败。这样主从复制就出现了问题，也导致基于复制的高可用系统不再安全。
MySQL 8.0 推出新特性 - 原子 DDL，解决了以上的问题。
DDL 是指数据定义语言（Data Definition Language），负责数据结构的定义与数据对象的定义。原子 DDL 是指一个 DDL 操作是不可分割的，要么全成功要么全失败。
MySQL 8.0 只有 InnoDB 存储引擎支持原子 DDL。
支持语句：数据库、表空间、表、索引的 CREATE、ALTER 以及 DROP 语句，以及 TRUNCATE TABLE 语句。
MySQL 8.0 系统表均以 InnoDB 存储引擎存储，涉及到字典对象的均支持原子 DDL。
支持的语句：存储过程、触发器、视图以及用户定义函数（UDF）的 CREATE 和 DROP 、ALTER 操作，用户和角色的 CREATE、ALTER、DROP 语句，以及适用的 RENAME 语句，以及 GRANT 和 REVOKE 语句。
不支持的语句：
INSTALL PLUGIN、UNINSTALL PLUGININSTALL COMPONENT、UNINSTALL COMPONENTREATE SERVER、ALTER SERVER、DROP SERVER首先，8.0 将字典信息存放到事务引擎的系统表（InnoDB 存储引擎）中。这样 DDL 操作转变成一组对系统表的 DML 操作，从而失败后可以依据事务引擎自身的事务回滚保证系统表的原子性。
似乎 DDL 原子性就此就可以完成，但实际上并没有这么简单。首先字典信息不光是系统表，还有一组字典缓存，如：
Table Share 缓存DD 缓存InnoDB 中的 dict此外，字典信息只是数据库对象的元数据，DDL 操作不光要修改字典信息，还要实实在在的操作对象，以及对象本身在内存中缓存。
表空间Dynamic metaBtreeibd 文件buffer pool 中表空间的 page 页此外，binlog 也要考虑 DDL 失败的情况。
因此，原子 DDL 在处理 DDL 失败的时候，不光是直接回滚系统表的数据，而且也要保证内存缓存，数据库对象也能回滚到一致状态。
为了解决 DDL 失败情况中数据库对象的回滚，8.0 引入了系统表 DDL_LOG。该表在 mysql 库中。不可见，也不能人为操作。如果想了解该表的结果，先编译一个 debug 版的 MySQL：
SET SESSION debug='+d,skip_dd_table_access_check'; show create table mysql.innodb_ddl_log;
可以看到如下表结构：
CREATE TABLE `innodb_ddl_log` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT, `thread_id` bigint unsigned NOT NULL, `type` int unsigned NOT NULL, `space_id` int unsigned DEFAULT NULL, `page_no` int unsigned DEFAULT NULL, `index_id` bigint unsigned DEFAULT NULL, `table_id` bigint unsigned DEFAULT NULL, `old_file_path` varchar(512) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, `new_file_path` varchar(512) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, PRIMARY KEY (`id`), KEY `thread_id` (`thread_id`) ) /*!50100 TABLESPACE `mysql` */ ENGINE=InnoDB AUTO_INCREMENT=48 DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0 ROW_FORMAT=DYNAMIC
在 8.0 中，这个表需要满足两个场景以及两个任务：
场景 1: 符合 DDL 失败的场景，需要回滚部分完成的 DDL。场景 2：DDL 进行中，发生故障（掉电、软硬件故障等），重启机器需要完成部分 DDL。两个任务：
任务 1：失败后回滚，执行反向操作。任务 2：如果成功，则执行清理工作。也许有人会问，为什么执行成功需要执行清理工作呢？
之所以要执行清理工作，因为 ibd 文件和索引一旦删除就不能恢复。为了实现回滚，DDL 删除这些对象时候，并不是真正删除，而是先将它们备份一下，以备回滚时使用。所以只有确认 DDL 已经执行成功，这些备份对象不需要了，才执行清理工作。
为了将这个原理将清楚，我们流程相对简单的 CREATE TABLE 讲起，管中窥豹，可见一斑。假设已经有编译好了 8.0 debug 版本，并且 innodb_file_per_table 为 on，先执行以下命令：
mysql> set global log_error_verbosity=3; Query OK, 0 rows affected (0.00 sec) mysql> set global innodb_print_ddl_logs = on; Query OK, 0 rows affected (0.00 sec)
从而开启了 ddl log 的日志，然后创建表：
mysql> create table t2 (a int); Query OK, 0 rows affected (25 min 26.42 sec)
可以看到如下日志：
XXXXX 8 [Note] [MY-012473] [InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=20, thread_id=8, space_id=6, old_file_path=./test/t2.ibd] XXXXX 8 [Note] [MY-012478] [InnoDB] DDL log delete : 20 XXXXX 8 [Note] [MY-012477] [InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=21, thread_id=8, table_id=1067, new_file_path=test/t2] XXXXX 8 [Note] [MY-012478] [InnoDB] DDL log delete : 21 XXXXX 8 [Note] [MY-012472] [InnoDB] DDL log insert : [DDL record: FREE, id=22, thread_id=8, space_id=6, index_id=157, page_no=4] XXXXX 8 [Note] [MY-012478] [InnoDB] DDL log delete : 22 XXXXX 8 [Note] [MY-012485] [InnoDB] DDL log post ddl : begin for thread id : 8 XXXXX 8 [Note] [MY-012486] [InnoDB] DDL log post ddl : end for thread id : 8
create table 的 DDL 只有反向操作日志记录，而无清理操作日志记录。细心的读者可能看到日志中插入某条 DDL log，随后又将其删除，会心生疑惑。但这正是 MySQL 原子 DDL 的秘密所在。我们选 DELETE SPACE 这个 DDL 日志写入函数 Log_DDL::write_delete_space_log 来揭秘这个过程。
dberr_t Log_DDL::write_delete_space_log(trx_t *trx, const dict_table_t *table,
space_id_t space_id,
const char *file_path, bool is_drop,
bool dict_locked) {
ut_ad(trx == thd_to_trx(current_thd));
ut_ad(table == nullptr || dict_table_is_file_per_table(table 来源：https://www.51cto.com/article/719146.html
