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 中的內容，需要
SET GLOBAL?LOG_ERROR_VERBOSITY=3;（MySQL 8.0 默認為2，error log 記錄Errors and
warnings，不?記錄notes）
SET GLOBAL innodb_print_ddl_logs=1;
CREATE TABLE?t1 (c1 INT)?ENGINE?=?InnoDB;
查看error log
[Note] [MY-011066] InnoDB: DDL log?insert?: [DDL?record:?DELETE SPACE,?id=30,
thread_id=25, space_id=9, old_file_path=./test/t1.ibd]
[Note] [MY-011066]?InnoDB:?DDL log?delete?:?by id?30
[Note] [MY-011066]?InnoDB:?DDL log?insert?: [DDL?record: REMOVE?CACHE,?id=31,
thread_id=25, table_id=1066, new_file_path=test/t1]
[Note] [MY-011066]?InnoDB:?DDL log?delete?:?by id?31
[Note] [MY-011066]?InnoDB:?DDL log?insert?: [DDL?record: FREE,?id=32, thread_
id=25, space_id=9, index_id=143, page_no=4]
[Note] [MY-011066]?InnoDB:?DDL log delete?:?by id?32
[Note] [MY-011066]?InnoDB:?DDL log?post ddl :?begin for thread id?: 25
[Note] [MY-011066]?InnoDB:?DDL log?post ddl :?end for thread id?: 25
原子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的到來吧！