MySQL 8.0開始支援原子資料定義語言(DDL)語句。此功能稱為原子DDL。原子DDL語句将與DDL操作關聯的資料字典更新，存儲引擎操作和二進制日志寫入組合到單個原子事務中。即使伺服器在操作期間暫停，也會送出事務，并将适用的更改保留到資料字典，存儲引擎和二進制日志，或者復原事務。
通過在MySQL 8.0中引入MySQL資料字典，可以實作Atomic DDL。在早期的MySQL版本中，中繼資料存儲在中繼資料檔案，非事務性表和存儲引擎特定的字典中，這需要中間送出。MySQL資料字典提供的集中式事務中繼資料存儲消除了這一障礙，使得将DDL語句操作重組為原子事務成為可能。
官方文檔：
https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html
1、支援的DDL語句
原子DDL功能支援表和非表DDL語句。與表相關的DDL操作需要存儲引擎支援，而非表DDL操作則不需要。目前，隻有InnoDB存儲引擎支援原子DDL。
①：受支援的表DDL語句包括 CREATE，ALTER和 DROP對資料庫，表，表和索引，以及語句 TRUNCATE TABLE聲明。
②：支援的非表DDL語句包括：
CREATE和DROP 語句，以及(如果适用)ALTER 存儲程式，觸發器，視圖和使用者定義函數(UDF)的語句。
賬戶管理語句： CREATE，ALTER， DROP，，如果适用， RENAME報表使用者和角色，以及GRANT 和REVOKE報表。
1.1、原子DDL功能不支援以下語句：
①：涉及除存儲引擎之外的存儲引擎的與表相關的DDL語句InnoDB。
②：INSTALL PLUGIN和 UNINSTALL PLUGIN 陳述。
③：INSTALL COMPONENT和 UNINSTALL COMPONENT 陳述。
④：CREATE SERVER， ALTER SERVER和 DROP SERVER語句。
2、原子DDL特性：
①：中繼資料更新，二進制日志寫入和存儲引擎操作(如果适用)将合并為單個事務。
②：在DDL操作期間，SQL層沒有中間送出。
③：在适用的情況下：
資料字典，程式，事件和UDF高速緩存的狀态與DDL操作的狀态一緻，這意味着更新高速緩存以反映DDL操作是成功完成還是復原。
DDL操作中涉及的存儲引擎方法不執行中間送出，并且存儲引擎将自身注冊為DDL事務的一部分。
存儲引擎支援DDL操作的重做和復原，這在DDL操作的 Post-DDL階段執行。
④：DDL操作的可見行為是原子的，這會更改某些DDL語句的行為
注意：
原子或其他DDL語句隐式結束目前會話中處于活動狀态的任何事務，就好像您COMMIT在執行語句之前完成了一樣。這意味着DDL語句不能在另一個事務中，在事務控制語句中執行 START TRANSACTION ... COMMIT，或者與同一事務中的其他語句結合使用。
3、DDL語句行為的變化
3.1、DROP TABLE：
如果所有命名表都使用原子DDL支援的存儲引擎，則操作是完全原子的。該語句要麼成功删除所有表，要麼復原。
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)
注意：
由于行為的這種變化，DROP TABLE會在 MySQL 5.7主伺服器上的部分完成 語句在MySQL 8.0從伺服器上複制時失敗。要避免此故障情形，請在DROP TABLE語句中使用IF EXISTS文法以防止對不存在的表發生錯誤
3.2、DROP DATABASE：
如果所有表都使用原子DDL支援的存儲引擎，則為atomic。該語句要麼成功删除所有對象，要麼復原。但是，從檔案系統中删除資料庫目錄是最後一次，并且不是原子事務的一部分。如果由于檔案系統錯誤或伺服器暫停而導緻資料庫目錄的删除失敗， DROP DATABASE則不會復原事務。
3.3、對于不使用原子DDL支援的存儲引擎的表，表删除發生在原子 DROP TABLE或 DROP DATABASE事務之外。這樣的表删除被單獨寫入二進制日志，這在中斷DROP TABLE或 DROP DATABASE操作的情況下将存儲引擎，資料字典和二進制日志之間的差異限制為最多一個表 。對于删除多個表的操作，不使用原子DDL支援的存儲引擎的表将在執行之前删除。
3.4、CREATE TABLE， ALTER TABLE， RENAME TABLE， TRUNCATE TABLE， CREATE TABLESPACE，和 DROP TABLESPACE對使用原子DDL支援的存儲引擎表執行的操作要麼完全送出或如果伺服器的操作時停止復原。在早期的MySQL版本中，這些操作的中斷可能會導緻存儲引擎，資料字典和二進制日志之間的差異，或留下孤立檔案。RENAME TABLE如果所有命名表都使用原子DDL支援的存儲引擎，則操作隻是原子操作。
3.5、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 |
+----------------+------------+
在引入原子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)
注意：
由于行為的這種變化，DROP VIEW在MySQL 5.7主伺服器上的部分完成 操作在MySQL 8.0從伺服器上複制時會失敗。要避免此故障情形，請在DROP VIEW語句中使用IF EXISTS文法以防止對不存在的視圖發生錯誤。
3.6、不再允許部分執行帳戶管理聲明。帳戶管理語句對所有命名使用者成功或復原，如果發生錯誤則無效。在早期的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文法，以防止與命名使用者相關的錯誤。
4、存儲引擎支援：目前隻有innodb存儲引擎支援原子DDL
目前，隻有InnoDB存儲引擎支援原子DDL。不支援原子DDL的存儲引擎免于DDL原子性。涉及豁免存儲引擎的DDL操作仍然能夠引入操作中斷或僅部分完成時可能發生的不一緻。
要支援重做和復原DDL操作， InnoDB請将DDL日志寫入 mysql.innodb_ddl_log表，該表是駐留在mysql.ibd資料字典表空間中的隐藏資料字典表 。
要mysql.innodb_ddl_log在DDL操作期間檢視寫入表的DDL日志 ，請啟用 innodb_print_ddl_logs 配置選項。
注意：
mysql.innodb_ddl_log無論innodb_flush_log_at_trx_commit 設定多少，對表的 更改的重做日志 都會立即重新整理到磁盤 。立即重新整理重做日志可以避免DDL操作修改資料檔案的情況，但是mysql.innodb_ddl_log由這些操作産生的對表的更改的重做日志 不會持久儲存到磁盤。這種情況可能會在復原或恢複期間導緻錯誤。
InnoDB存儲引擎分階段執行DDL操作。DDL操作 ALTER TABLE可以在Commit階段之前多次執行 Prepare和Perform階段：
準備：建立所需對象并将DDL日志寫入 mysql.innodb_ddl_log表中。DDL日志定義了如何前滾和復原DDL操作。
執行：執行DDL操作。例如，為CREATE TABLE操作執行建立例程。
送出：更新資料字典并送出資料字典事務。
Post-DDL：重播并從mysql.innodb_ddl_log表中删除DDL日志。為了確定可以安全地執行復原而不引入不一緻性，在最後階段執行檔案操作，例如重命名或删除資料檔案。這一階段還從删除的動态中繼資料 mysql.innodb_dynamic_metadata的資料字典表DROP TABLE，TRUNCATE TABLE和該重建表其他DDL操作。
注意：
無論事務是送出還是復原， DDL日志都會在Post-DDL階段重播并從表中删除 。mysql.innodb_ddl_log如果伺服器在DDL操作期間暫停，則DDL日志應僅保留在表中。在這種情況下，DDL日志将在恢複後重播并删除。
在恢複情況下，可以在重新啟動伺服器時送出或復原DDL事務。如果在重做日志和二進制日志中存在在DDL操作的送出階段期間執行的資料字典事務，則 該操作被視為成功并且前滾。否則，在InnoDB重放資料字典重做日志時復原不完整的資料字典事務 ，并復原DDL事務。
5、檢視DDL日志：
InnoDB将DDL日志寫入 mysql.innodb_ddl_log表以支援重做和復原DDL操作。該 mysql.innodb_ddl_log表是隐藏在mysql.ibd資料字典表空間中的隐藏資料字典表 。與其他隐藏資料字典表一樣，mysql.innodb_ddl_log在非調試版本的MySQL中無法直接通路該 表。