详谈 MySQL 8.0 原子 DDL 原理

发布时间：2025-11-04 07:37:52 来源：云智核 作者：数据库

背景

MySQL 5.7 的详谈字典信息保存在非事务表中，并且存放在不同的原L原文件中（.FRM，.PAR，详谈.OPT，原L原.TRN，详谈.TRG 等)。原L原所有 DDL 操作都不是详谈 Crash Safe，而且对于组合 DDL（ALTER 多个表）会出现有的原L原成功有的失败的情况，而不是详谈总体失败。这样主从复制就出现了问题，原L原也导致基于复制的详谈高可用系统不再安全。

MySQL 8.0 推出新特性 - 原子 DDL，原L原解决了以上的详谈问题。

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 语句。

不支持的语句：

实现原理是什么？

首先，8.0 将字典信息存放到事务引擎的系统表（InnoDB 存储引擎）中。这样 DDL 操作转变成一组对系统表的网站模板 DML 操作，从而失败后可以依据事务引擎自身的事务回滚保证系统表的原子性。

似乎 DDL 原子性就此就可以完成，但实际上并没有这么简单。首先字典信息不光是系统表，还有一组字典缓存，如：

此外，字典信息只是数据库对象的元数据，DDL 操作不光要修改字典信息，还要实实在在的操作对象，以及对象本身在内存中缓存。

此外，binlog 也要考虑 DDL 失败的情况。

因此，原子 DDL 在处理 DDL 失败的时候，不光是直接回滚系统表的数据，而且也要保证内存缓存，数据库对象也能回滚到一致状态。

实现细节

为了解决 DDL 失败情况中数据库对象的回滚，8.0 引入了系统表 DDL_LOG。源码下载该表在 mysql 库中。不可见，也不能人为操作。如果想了解该表的结果，先编译一个 debug 版的 MySQL：

SET SESSION debug=+d,skip_dd_table_access_check;

可以看到如下表结构：

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`)

在 8.0 中，这个表需要满足两个场景以及两个任务：

两个任务：

也许有人会问，为什么执行成功需要执行清理工作呢？

之所以要执行清理工作，因为 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;

从而开启了 ddl log 的日志，然后创建表：

mysql> create table t2 (a int);

可以看到如下日志：

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

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));

if (skip(table, trx->mysql_thd)) {

return (DB_SUCCESS);

}

uint64_t id = next_id();

ulint thread_id = thd_get_thread_id(trx->mysql_thd);

dberr_t err;

trx->ddl_operation = true;

DBUG_INJECT_CRASH("ddl_log_crash_before_delete_space_log",

crash_before_delete_space_log_counter++);

if (is_drop) { //（1）

err = insert_delete_space_log(trx, id, thread_id, space_id, file_path,

dict_locked);

if (err != DB_SUCCESS) {

return err;

}

DBUG_INJECT_CRASH("ddl_log_crash_after_delete_space_log",

crash_after_delete_space_log_counter++);

} else { // （2）

err = insert_delete_space_log(nullptr, id, thread_id, space_id, file_path,

dict_locked);

if (err != DB_SUCCESS) {

return err;

}

DBUG_INJECT_CRASH("ddl_log_crash_after_delete_space_log",

crash_after_delete_space_log_counter++);

DBUG_EXECUTE_IF("DDL_Log_remove_inject_error_2",

srv_inject_too_many_concurrent_trxs = true;);

err = delete_by_id(trx, id, dict_locked); //（3）

ut_ad(err == DB_SUCCESS || err == DB_TOO_MANY_CONCURRENT_TRXS);

DBUG_EXECUTE_IF("DDL_Log_remove_inject_error_2",

srv_inject_too_many_concurrent_trxs = false;);

DBUG_INJECT_CRASH("ddl_log_crash_after_delete_space_delete",

crash_after_delete_space_delete_counter++);

}

return (err);

在 create table​ 这个过程中调用 write_delete_space_log，is_drop​ 为 false​，执行以上代码执行分支 (2)​ 和 (3)​ 。注意的是 insert_delete_space_log​ 第一个参数为空，这意味着会在创建一个后台事务（调用 trx_allocate_for_background​）插入 DELETE_SPACE​ 记录到 innodb_ddl_log​ 表中，然后提交该事务。注意到 (3)​ 处 delete_by_id​ 第一个参数为 trx​ , 这里的 trx​ 即本次 DDL 的事务，(3)​ 所做的动作是在本次事务中删除 (2) 插入的记录。

为什么是这样的逻辑呢？

以下分两种情况来讨论，如上图所示：

其它 DDL log 记录的操作如 REMOVE CACHE​ 、FREE​ 日志记录的写入也是类似的逻辑。复杂的 DDL，不光是会插入反向操作日志记录，也会插入清理操作日志。比如 TRUNCATE​ 表操作会将原有的表空间重命名为一个零时表空间，当 DDL 成功之后，需要通过 post_ddl​ Replay DDL log 记录，将临时表空间删除。如果失败，又需要 post_ddl​ 重演 DDL log，执行反向操作，将临时表空间重命名为原来的表空间。总之，如果是反向操作日志，则使用 background trx​ 插入并提交，然后使用 trx​ 删除；如果是清理日志，则使用 trx 插入即可。

注意：innodb_ddl_log 表与其他 InnoDB 表一样，对该表所有操作 InnoDB 引擎都会产生 Redo 日志与 Undo 记录，所以不要将 DDL log 表中反向操作记录看作 Undo log，这两者不在同一个抽象层次上。而且反向操作在另一个事务中执行，而回滚时，Undo log 则是在原有同一个事务上执行。

需要探讨的几个问题

我们知道 MySQL 有一个 innodb_flush_log_at_trx_commit 参数，当设置为 0 时，提交时并不会立刻将 Redo log 刷入持久存储中。虽然能提高性能，但在掉电或者停机时会有一定概率丢失已经提交的事务。对于 DML 操作来说，这样仅仅是丢失事务，但对于 DDL 来说，丢失 DDL 的事务，就会导致数据库元数据与其他数据不一致，以至数据库系统无法正常工作。

所以，在 trx_commit 会根据该事务是否为 DDL 操作，进行特殊处理：

无论 innodb_flush_log_at_trx_commit 参数如何设置，与 DDL 有关的事务，提交时必须日志刷盘！

在理解了 DDL log 的机制之后，笔者问大家一个问题，对于 create table​ 来说，是先执行 write_delete_space_log 还是先创建表空间呢？

我们先假设是先创建表空间（A 动作），再写反向操作日志（B 动作）。如果 A 执行结束后出现掉的情况，此时 B 还未执行，此时 create table​ 动作并没有完成，而 innodb_ddl_log​ 不存在 DELETE SPACE​ 这样的 DDL 反向日志记录，数据库崩溃恢复后，数据库系统会将系统表数据回滚，但是 A 创建的表空间却没有删除，由于存在中间状态，此时 create table 就不是原子 DDL 了。

所以，在 DDL 中每个步骤中，先写入该步骤的反向操作日志记录到 innodb_ddl_log​ ，再执行该步骤。也就是说 DDL Log 写入时机在执行步骤之前。如果 create table​ 已经写入了 DDL log， 但是没有创建表空间就出现掉电情况呢？ 这并不要紧，在 post_ddl 做 Replay 的时候，会进行处理。

在 DDL 操作完成之后，无论 DDL 的事务提交还是回滚，都会调用 post_ddl​ 函数，post_ddl​ 则会调用 replay​ 函数进行 Replay。此外，MySQL 8.0 数据库崩溃恢复过程中，与 MySQL 5.7 相比，也多了 ha_post_recover​ 的过程，它会调用 log_ddl->recover​ 将 innodb_ddl_log 所有的日志记录进行 Replay。

在 post_ddl​ 调用的是 replay_by_thread_id​，崩溃恢复中 ha_post_recover​ 调用的是 replay_all，其逻辑如下描述：

可以看到，以上两个函数都有将记录逆序的获取的过程，为什么要逆序呢？

(1) 反向操作

我们如果将 DDL 中每个步骤看做一个函数，参数为数据库系统。假设第 i 个步骤函数为 oi，那么 n 个步骤就是 n 个函数的复合函数：

也即，复合函数的逆时所有步骤逆函数的反向复合。所以反向操作需要将 DDL log 逆序进行处理。

(2) 清理操作

DDL 的清理动作往往没有顺序要求，逆向操作与正向操作效果往往是一样的，所以统一进行逆序处理也没有问题。

与 Redo、Undo 类似，每个类型的日志重演均要考虑其幂等性。

所谓幂等性，就是执行多次和执行一次的效果是一样的。特别是在崩溃恢复的时候，在重演反向操作的时候，尚未完成时发生掉电故障，重新进行崩溃恢复。此时某项重演操作可能发生多次。

因此，MySQL 8.0 实现这些重演操作，必须要考虑幂等性。最典型是重演一些删除操作，必须先判断数据库对象是否存在。如果存在，才进行删除，否则什么都不做。

Tips：说到这里，笔者推荐一本书《具体数学：计算机科学中的一块基石》此书讲解了许多计算机科学中用到的数学知识及技巧，并特别著墨于算法分析方面。

注意事项

MySQL 8.0 支持原子 DDL，并不意味着 DDL 可以通过 SQL 语句命令进行回滚。实际上除了 SQLServer 外，几乎所有的数据库系统不支持 DDL 的 SQL 命令进行回滚，DDL 回滚引入的问题远远多于其带来的好处。

MySQL 8.0 只承诺单个 DDL 语句的原子性，并不能保证多个 DDL 组合也能保持原子性。某大厂为了实现 Truncate table flashback​ ，仅仅在 MySQL 的 Server 层将 truncate table​ 动作转换为 rename table 动作，flashback 的时候将表、索引、约束重新以 RENAME DDL 组合执行来实现 flashback，这个是及其危险的，不保证其原子性。笔者也完成过此功能，并没有如此取巧，而是老老实实的从 Server 层、InnoDB 存储引擎、binlog 各方面进行改造，完整保证其原子性。

MySQL 8.0 用这种方法实现原子 DDL，并不意味着其它数据库也是这种方式实现原子 DDL。

相关文章