## 背景 MySQL保存了兩份元數據，一份在server層，保存在FRM文件中，另外一份在引擎層，比如InnoDB的數據字典中，這樣也就造成了DDL語句經常導致元數據不一致的情況，下面介紹兩個近期出現的因為DDL產生的bug。 ### rename 外鍵引用的column BUG復現過程 ~~~ CREATE TABLE t1 (a INT NOT NULL, b INT NOT NULL, INDEX idx(a)) ENGINE=InnoDB; CREATE TABLE t2 (a INT KEY, b INT, INDEX ind(b), FOREIGN KEY (b) REFERENCES t1(a) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB; ALTER TABLE t1 CHANGE a id INT; ~~~ 在DEBUG版本下，MySQL實例是crash的，crash在?`handler0alter.cc`?line 5643。 BUG原因分析 在做alter語句的時候，因為rename的column關聯有foreign key，所以需要在數據字典中更改這個foreign key，但在數據字典緩存中還保留了一份foreign對象，代碼只做了持久化的更改，在重新`dict_load_foreigns()`的時候，和緩存中的foreign key沖突，導致函數報錯。 BUG修復方法 BUG修復也比較簡單，在rename的過程中，先更改數據字典，然后調用`dict_foreign_remove_from_cache`函數清理內存中的對象，這樣在重新`dict_load_foreigns`的時候，就一切正常了。 MySQL官方版本在5.6.23修復了這個問題。 ## alter 添加和刪除索引導致不一致 BUG復現過程 ~~~ CREATE TABLE t1(id INT, col1 INT, col2 INT, KEY(col1))ENGINE=InnoDB; alter table t1 add key(col2), drop key col1; ~~~ 復現此BUG的時候需要使用DEBUG_SYNC，在alter table的過程中，add key(col2)步驟成功，而在drop key的時候InnoDB報失敗。 然后導致MySQL server層對表t1的定義和InnoDB層的定義不一致。 BUG原因分析 在drop key報引擎失敗的時候，MySQL server層開始回滾整個DDL語句，server層這時回滾了FRM的定義，而InnoDB成功添加的key(col2)卻沒有回滾。 BUG修復方法 在alter的過程中，記錄每一個階段成功的調用，在語句結束的時候，如果遇到需要回滾的statement，需要同時回滾引擎層和server層。 因為MySQL保存了兩份元數據，也造成在DDL變更的過程中，無法保證數據的一致性。