MySQL8.0新特性——支持原子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中無法直接訪問該 表。
MySQL8.0新特性——支持原子DDL語句