文章來源：愛可生雲資料庫
簡介
MySQL8.0 開始支援原? DDL(atomic DDL)，資料字典的更新，存儲引擎操作，寫?進制日志結合成了一個事務。在沒有原?DDL之前，DROP TABLE test1,test2；如遇到server crash，可能會有test1被drop了，test2沒有被drop掉。下面來看下在MySQL8.0之前和MySQL8.0 資料字典的差別。
在MySQL8.0 之前，Data Dictionary除了存在與.FRM, .TRG, .OPT ?件外，還存在于系統表中(MyISAM ?事務引擎表中)，在MySQL8.0 ，Data Dictionary 全部存在于Data Dictionary Storage Engine(即 InnoDB表中)，這使crash recovery 維持原?性成為了可能。
存儲引擎?持
目前，隻有InnoDB存儲引擎?持原子DDL，為了實作原子DDL，Innodb要寫DDL logs 到 mysql.innodb_ddl_log 表，這是?個隐藏在mysql.ibd 資料字典表空間?的資料字典表。要看mysql.innodb_ddl_log 中的内容，需要
檢視error log
原子DDL 操作步驟
準備：建立所需的對象并将DDL?志寫入 mysql.innodb_ddl_log表中。DDL日志定義了如何前滾和復原DDL操作。
執行：執?DDL操作。例如，為CREATE TABLE操作執?建立。
送出：更新資料字典并送出資料字典事務。
Post-DDL：重播并從mysql.innodb_ddl_log表格中删除DDL?志。為確定復原可以安全執??不引?不?緻性，在此最後階段執??件操作(如重命名或删除資料檔案)。這一階段還從 mysql.innodb_dynamic_metadata的資料字典表删除的動态中繼資料為了DROP TABLE，TRUNCATE和其它重建表的DDL操作。
?論事務是送出還是復原，DDL日志都會mysql.innodb_ddl_log在Post-DDL階段重播并從表中删除 。mysql.innodb_ddl_log如果伺服器在DDL操作期間暫停，DDL?志應該隻保留在表中。在這種情況下，DDL?志會在恢複後重播并删除。
在恢複情況下，當伺服器重新啟動時，可能會送出或回退DDL事務。如果在重做?志和?進制日志中存在DDL操作的送出階段期間執?的資料字典事務，則該操作被認為是成功的并且被前滾。否則，在InnoDB重放資料字典重做日志時復原不完整的資料字典事務 ，并且復原DDL事務。
原?DDL ?持類型
? DROP TABLES , all tables dropped or none
? DROP SCHEMA, all entities in the schema are dropped, or none
? Note that atomic DDL statements will be rolled back or committed even in case of crash, e.g. RENAME TABLES
? CREATE TABLE would be successfully committed or rolled back (no orphan ibd left)
? TRUNCATE TABLE (including InnoDB tables with FTS AUX tables) would be successfully committed or rolled back
? RENAME TABLES, all or none
? ALTER TABLE successful or not done
示例
結論
在MySQL8.0之前，alter table 操作在server crash的情況下，會遺留.frm,.ibd檔案。MySQL8.0 能實作原?DDL(包括 DROP TABLE, DROP SCHEMA, CREATE TABLE, TRUNCATE TABLE, ALTER TABLE)，alter table 操作，在server crash的情況下，不會遺留.frm，.ibd臨時檔案。讓我們?起期待MySQL8.0 GA的到來吧！
參考：
https://www.youtube.com/watch?v=jM53hSU9L70
https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html