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語句隱式結束當前會話中處於活動狀態的任何事務，就好像您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中無法直接訪問該 表。