1.意义描述
MySQL 8.0支持原子数据定义语言（DDL）语句。此功能被称为原子DDL。原子DDL语句将与DDL操作相关联的数据字典更新、存储引擎操作和二进制日志写入合并为单个原子操作。该操作要么被提交，并将适用的更改持久化到数据字典、存储引擎和二进制日志中，要么被回滚，即使服务器在操作过程中停止。
注意：
原子DDL不是事务DDL。DDL语句，无论是原子语句还是其他语句，都会隐式地结束当前会话中活动的任何事务，就好像在执行该语句之前执行了COMMIT一样。这意味着DDL语句不能在另一个事务中执行，也不能在事务控制语句（如START transaction…）中执行。。。COMMIT，或与同一事务中的其他语句组合。
博主PS：
DDL（data definition language）是数据定义语言：DDL比DML要多，主要的命令有CREATE、ALTER、DROP
通过在MySQL 8.0中引入MySQL数据字典，Atomic DDL成为可能。在早期的MySQL版本中，元数据存储在元数据文件、非事务表和特定于存储引擎的字典中，这就需要进行中间提交。MySQL数据字典提供的集中式、事务性元数据存储消除了这一障碍，使DDL语句操作可以重新构造为原子操作。
2.功能描述
2.1 支持的DDL语句
原子DDL功能同时支持表和非表DDL语句。与表相关的DDL操作需要存储引擎支持，而非表DDL操作则不需要。目前，只有InnoDB存储引擎支持原子DDL。
支持的表DDL语句:
数据库、表空间、表和索引的CREATE、ALTER和DROP语句，以及 TRUNCATE TABLETRUNCATE TABLETRUNCATE TABLE语句。
支持的非表DDL语句包括：
CREATE和DROP语句，以及存储程序、触发器、视图和可加载函数的ALTER语句（如果适用）。
帐户管理语句：
CREATE、ALTER、DROP，以及用户和角色的RENAME语句（如果适用），以及GRANT和REVOKE语句。
原子DDL功能不支持以下语句：
- 涉及InnoDB以外的存储引擎的表相关DDL语句。
- INSTALL PLUGIN和UNINSTALL PLUGING语句。
- INSTALL COMPONENT和UNINSTALL COMPONMENT语句。
- CREATE SERVER、ALTER SERVER和DROP SERVER语句。
2.2 原子DDL特性
原子DDL语句的特征包括以下内容：
元数据更新、二进制日志写入和存储引擎操作（如果适用）组合为一个原子操作。在DDL操作期间，SQL层没有中间提交。
适用：
数据字典、例程、事件和可加载函数缓存的状态与DDL操作的状态一致，这意味着缓存会更新以反映DDL操作是否成功完成或回滚。
DDL操作中涉及的存储引擎方法不执行中间提交，存储引擎将自己注册为DDL操作的一部分。
存储引擎支持DDL操作的重做和回滚，这是在DDL操作的后DDL阶段执行的。
DDL操作的可见行为是原子行为，它会更改某些DDL语句的行为。请参阅DDL语句行为中的更改。
2.3 DDL语句行为的更改
本节介绍由于引入原子DDL支持而导致的DDL语句行为的变化。
2.3.1 DROP TABLE
如果所有命名表都使用原子DDL支持的存储引擎，则DROP TABLE操作是完全原子的。该语句要么成功删除所有表，要么回滚。
如果命名表不存在，并且不进行任何更改（无论存储引擎如何），则DROP TABLE将失败并返回错误。下面的示例演示了这种行为变化，其中DROP TABLE语句由于不存在命名表而失败：
mysql> CREATE TABLE t1 (c1 INT);
mysql> DROP TABLE t1, t2;
ERROR 1051 (42S02): Unknown table 'test.t2'
mysql> SHOW TABLES;
+----------------+
| Tables_in_test |
+----------------+
| t1 |
+----------------+在引入原子DDL之前，DROP TABLE会为不存在的表报告错误，但为存在的表报告成功：
mysql> CREATE TABLE t1 (c1 INT);
mysql> DROP TABLE t1, t2;
ERROR 1051 (42S02): Unknown table 'test.t2'
mysql> SHOW TABLES;
Empty set (0.00 sec)博主PS：这块好理解，就是没有DDL原子语义之前，你执行一条需要操作两个表的sql时，就算有个表因为不存在而失败了，对另外一个表的操作也会成功，可以看见示例中，虽然t2
表不存在报错了，t1表也被删除了。这种就是非原子性的。
注意：
由于此行为变化，在MySQL 5.7复制源服务器上部分完成的DROP TABLE语句在MySQL 8.0复制副本上复制时失败。为了避免这种失败情况，请在DROP TABLE语句中使用IF EXISTS语法，以防止不存在的表出现错误。
2.3.2 DROP DATABASE
如果所有表都使用原子DDL支持的存储引擎，那么DROP DATABASE就是原子数据库。该语句要么成功删除所有对象，要么回滚。但是，从文件系统中删除数据库目录是最后一次，并且不是原子操作的一部分。如果由于文件系统错误或服务器停止而导致数据库目录删除失败，则DROP database事务不会回滚。
2.3.2 DROP DATABASE
对于使用不支持DDL的原子存储引擎的表，表删除发生在原子DROP table或DROP DATABASE事务之外。这样的表删除被单独写入二进制日志（Binlog），这将在DROP table或DROP DATABASE操作中断的情况下，存储引擎、数据字典和二进制日志之间的数据差异限制为最多一个表。对于删除多个表的操作，使用不支持DDL原子存储引擎的表会先删除，然后再删除支持的。
2.4 存储引擎支持
使用原子DDL支持的存储引擎的表的语句：
2.4.1 孤立文件
CREATE TABLE、ALTER TABLE、RENAME TABLE、TRUNCATE TABLE、CREATE TABLESPACE和DROP TABLESPACE操作将完全提交，或者在服务器运行期间停止时回滚。
在早期的MySQL版本中，这些操作的中断可能会导致存储引擎、数据字典和二进制日志之间的差异，或者留下孤立文件。
如果所有表都使用原子DDL支持的存储引擎，RENAME TABLE操作才为原子操作。
2.4.2 基于行的复制
从MySQL 8.0.21开始，在支持原子DDL的存储引擎上，CREATE TABLE....SELECT 当使用基于行的复制时，SELECT语句作为一个事务记录在二进制日志中。
以前，它被记录为两个事务，一个用于创建表，另一个用于插入数据。两个事务之间的服务器故障或插入数据时的服务器故障可能导致空表的复制。
随着原子DDL支持的引入，CREATE TABLE...SELECT语句现在对于基于行的复制是安全的，并且允许与基于GTID的复制一起使用。
2.4.3 外键约束
在同时支持原子DDL和外键约束的存储引擎上，使用基于行的复制时的SELECT语句不允许在CREATE TABLE....SELECT 中创建外键。可以使用ALTER TABLE添加外键约束。
当CREATE TABLE...SELECT作为一个原子操作应用，在插入数据时会在表上保留元数据锁，从而在操作期间防止对表的并发访问。
2.4.4 视图
如果命名视图不存在并且未进行任何更改，则DROP VIEW将失败。此示例演示了行为的更改，其中DROP VIEW语句由于不存在命名视图而失败：
mysql> CREATE VIEW test.viewA AS SELECT * FROM t;
mysql> DROP VIEW test.viewA, test.viewB;
ERROR 1051 (42S02): Unknown table 'test.viewB'
mysql> SHOW FULL TABLES IN test WHERE TABLE_TYPE LIKE 'VIEW';
+----------------+------------+
| Tables_in_test | Table_type |
+----------------+------------+
| viewA | VIEW |
+----------------+------------+博主PS：这里和上文提到的对多个表的DDL操作会回滚一个道理
在引入原子DDL之前，DROP VIEW会为不存在的命名视图返回一个错误，但会为存在的命名查看返回成功：
mysql> CREATE VIEW test.viewA AS SELECT * FROM t;
mysql> DROP VIEW test.viewA, test.viewB;
ERROR 1051 (42S02): Unknown table 'test.viewB'
mysql> SHOW FULL TABLES IN test WHERE TABLE_TYPE LIKE 'VIEW';
Empty set (0.00 sec)注意：
由于此行为变化，在MySQL 5.7复制源服务器上部分完成的DROP VIEW操作在MySQL 8.0复制副本上复制时失败。为了避免这种失败情况，请在DROP VIEW语句中使用IF EXISTS语法，以防止不存在的视图发生错误。
不再允许部分执行帐户管理报表。帐户管理语句要么对所有命名用户成功，要么回滚，如果发生错误则无效。在早期的MySQL版本中，命名多个用户的帐户管理语句可能对某些用户成功，对其他用户失败。
此示例演示了行为的更改，其中第二个CREATE USER语句返回一个错误，但由于无法对所有命名用户成功，因此失败。
mysql> CREATE USER userA;
mysql> CREATE USER userA, userB;
ERROR 1396 (HY000): Operation CREATE USER failed for 'userA'@'%'
mysql> SELECT User FROM mysql.user WHERE User LIKE 'user%';
+-------+
| User |
+-------+
| userA |
+-------+在引入原子DDL之前，第二个CREATE USER语句为不存在的命名用户返回一个错误，但为存在的指定用户返回成功：
mysql> CREATE USER userA;
mysql> CREATE USER userA, userB;
ERROR 1396 (HY000): Operation CREATE USER failed for 'userA'@'%'
mysql> SELECT User FROM mysql.user WHERE User LIKE 'user%';
+-------+
| User |
+-------+
| userA |
| userB |
+-------+注意:
由于这种行为的变化，在MySQL 5.7复制源服务器上部分完成的帐户管理语句在MySQL 8.0复制副本上复制时会失败。为了避免这种失败情况，请在帐户管理语句中酌情使用IF EXISTS或IF NOT EXISTS语法，以防止出现与命名用户相关的错误。
目前，只有InnoDB存储引擎支持原子DDL。不支持原子DDL的存储引擎不受DDL原子性的约束。涉及不支持原子DDL的存储引擎的DDL操作仍然能够引入操作中断或仅部分完成时可能出现的不一致。
2.4.5 innodb_ddl_log
为了支持DDL操作的重做和回滚，InnoDB将DDL日志写入 mysql.innodb_ddl_log 表，这是一个隐藏的数据字典表，位于mysql.ibd数据字典表空间中。
要查看在DDL操作期间写入mysql.innodb_DDL_log表的DDL日志，请启用innodb_print_ddl_logs配置选项。有关详细信息，请参阅查看DDL日志。
注意：
无论innodb_flush_log_at_trx_commit设置如何，mysql.innodb_ddl_log表更改的重做日志都会立即刷新到磁盘。立即刷新redolog可以避免DDL操作修改数据文件，但这些操作导致的对mysql.innodb_ddl_log表的更改的重做日志不会持久化到磁盘。这种情况可能会在回滚或恢复过程中导致错误。
2.4.6 执行DDL操作
InnoDB存储引擎分阶段执行DDL操作。DDL操作（如ALTER TABLE）可以在提交阶段之前多次执行准备和执行阶段。
准备：创建所需的对象，并将DDL日志写入mysql.innodb_ddl_log表。DDL日志定义了如何前滚和后滚DDL操作。
执行：执行DDL操作。例如，为CREATE TABLE操作执行创建例程。
提交：更新数据字典并提交数据字典事务。
发布DDL：从mysql.innodb_ddl_log表中回放并删除DDL日志。为了确保在不引入不一致的情况下安全地执行回滚，在最后阶段执行文件操作，如重命名或删除数据文件。此阶段还从mysql.innodb_dynamic_metadata数据字典表中删除DROP table、TRUNCATE table和其他重建该表的DDL操作的动态元数据。
在后DDL阶段，无论DDL操作是提交还是回滚，都会重播DDL日志，并从mysql.innodb_ddl_log表中删除DDL日志。如果服务器在DDL操作期间停止，则DDL日志应仅保留在mysql.innodb_ddl_log表中。在这种情况下，DDL日志会在恢复后重播并删除。
在系统恢复情况下，当服务器重新启动时，DDL操作可能会被提交或回滚。如果在DDL操作的提交阶段执行的数据字典事务存在于重做日志（redolog）和二进制日志（binlog）中，则该操作被视为成功并向前滚动。否则，当InnoDB回放数据字典重做日志时，会回滚不完整的数据字典事务，并回滚DDL操作。
2.5 查看DDL日志
要查看在涉及innodb存储引擎的原子DDL操作期间写入mysql.innodb_ddl_log数据字典表的DDL日志，请启用innodb_print_ddl_logs，让mysql将DDL日志写入stderr。根据主机操作系统和MySQL配置的不同，stderr可能是错误日志、终端或控制台窗口。参见第7.4.2.2节“默认错误日志目标配置”。
InnoDB将DDL日志写入mysql.innodb_ddl_log表，以支持DDL操作的重做和回滚。mysql.innodb_ddl_log表是一个隐藏的数据字典表，位于mysql.ibd数据字典表空间中。与其他隐藏数据字典表一样，在mysql的非调试版本中，不能直接访问mysql.innodb_ddl_log表。（参见第16.1节“数据字典模式”。）mysql.innodb_ddl_log表的结构对应于此定义：
CREATE TABLE mysql.innodb_ddl_log (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
thread_id BIGINT UNSIGNED NOT NULL,
type INT UNSIGNED NOT NULL,
space_id INT UNSIGNED,
page_no INT UNSIGNED,
index_id BIGINT UNSIGNED,
table_id BIGINT UNSIGNED,
old_file_path VARCHAR(512) COLLATE utf8mb4_bin,
new_file_path VARCHAR(512) COLLATE utf8mb4_bin,
KEY(thread_id)
);各字段解析
id：DDL日志记录的唯一标识符。
thread_id：为每个DDL日志记录分配一个thread_id，用于重播和删除属于特定DDL操作的DDL日志。涉及多个数据文件操作的DDL操作会生成多个DDL日志记录。
type：DDL操作类型。类型包括FREE（删除索引树）、DELETE（删除文件）、RENAME（重命名文件）或drop（从mysql.innodb_dynamic_metadata数据字典表中删除元数据）。
space_id：表空间id。
page_no：包含分配信息的页面；例如索引树根页面。
index_id：索引id。
table_id：表id。
old_file_path：旧的表空间文件路径。用于创建或删除表空间文件的DDL操作；也用于重命名表空间的DDL操作。
new_file_path：新的表空间文件路径。由重命名表空间文件的DDL操作使用。
此示例演示如何启用innodb_print_ddl_logs来查看为CREATE TABLE操作写入strderr的ddl日志。
mysql> SET GLOBAL innodb_print_ddl_logs=1;
mysql> CREATE TABLE t1 (c1 INT) ENGINE = InnoDB;[Note] [000000] InnoDB: DDL log insert : [DDL record: DELETE SPACE, id=18, thread_id=7,
space_id=5, old_file_path=./test/t1.ibd]
[Note] [000000] InnoDB: DDL log delete : by id 18
[Note] [000000] InnoDB: DDL log insert : [DDL record: REMOVE CACHE, id=19, thread_id=7,
table_id=1058, new_file_path=test/t1]
[Note] [000000] InnoDB: DDL log delete : by id 19
[Note] [000000] InnoDB: DDL log insert : [DDL record: FREE, id=20, thread_id=7,
space_id=5, index_id=132, page_no=4]
[Note] [000000] InnoDB: DDL log delete : by id 20
[Note] [000000] InnoDB: DDL log post ddl : begin for thread id : 7
[Note] [000000] InnoDB: DDL log post ddl : end for thread id : 7可以理解为strderr为操作mysql.innodb_ddl_log表的输出，而mysql.innodb_ddl_log表为DDL的逻辑日志。回看上文这段话
