MySQL online DDL的功能就是在對表就行DDL操作的同時也可以對表進行讀寫操作，即對表的DDL操作不會影響該表上的事務。

該功能的優點：

1. 改善繁忙生產環境的響應效率和可用性。
2. 可以使用lock子句在性能和並發性之間進行協調。
3. 相比ALGORITHM=COPY算法使用較少的磁盤空間和IO的開銷。

DDL online狀態支持表：

online DDL操作的相關語法：

創建二級索引：

CREATE INDEX name ON table (col_list);

ALTER TABLE table ADD INDEX name (col_list);

刪除二級索引：

在innodb表上創建和刪除二級索引不會產生table-copying

當索引正在被創建或刪除時，是可以對表進行讀寫操作的， 在對表執行create index或drop index語句時，只有在訪問該表的事務完成之後，create index和drop index語句才可以完成，所以索引的初始狀態反映了表中最近使用的數據，在以前，對正在執行create index或drop index的表進行操作時，會導致將insert，update，delete操作撤銷掉的死鎖。

online ddl的另外一個用法是，在進行數據遷移時，可以先創建表結構，然後導入數據，最後創建相關索引，這種方式通常會提高數據遷移的效率。

修改字段的屬性值：

ALTER TABLE tbl ALTER COLUMN col SET DEFAULT literal;

ALTER TABLE tbl ALTER COLUMN col DROP DEFAULT;

字段的默認值存儲在表的.frm文件中，而不是innodb的數據字典中。

修改字段的自增值：

ALTER TABLE table AUTO_INCREMENT=next_value;

在使用復制的分布式系統，或者是分片中，需要重新設置自增值到某一個指定的值，在數據倉庫中，有時需要清空表中的數據，然後重置自增值，再導入新的數據。

重命名字段名稱：

ALTER TABLE tbl CHANGE old_col_name new_col_name datatype;

當使用該語句只是修改字段的名稱，而沒有修改字段類型時，該語句的執行總是online的。

在對外鍵約束中的字段進行重命名後，在外鍵的定義中會自動將該字段的名稱更新為重命名後的名稱，對外鍵中的字段進行重命名操作時，該操作僅運行在 in-place模式，

當在修改語句中指定 ALGORITHM=COPY或者其他因素導致修改語句使用了 ALGORITHM=COPY，那麽重命名字段的語句將會執行失敗。

使用in-place模式修改varchar字段的長度：

ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(255);

每次修改varchar字段的長度時，varchar內部編碼需要的字節長度值一定要保持相同，因為varchar值從0-255時，需要1個字節長度來編碼值，當varchar從256字節開始需要2個字節長度來編碼值，所以當修改varchar字段的長度時，從0字節增加到255字節，或者從大於等於256字節開始增加長度都是支持in-place模式的，當從一個小於256字節的長度增加到大於256字節的長度，因為此時會導致varchar內部編碼值所需要的字節長度從1個字節長度變為2個字節長度，所以此時不能使用in-place模式，只能使用ALGORITHM=COPY模式，例如下述修改varchar長度的語句將會執行失敗：

ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256);

ERROR 0A000: ALGORITHM=INPLACE is not supported. Reason: Cannot change
column type INPLACE. Try ALGORITHM=COPY.

縮小varchar字段的長度時不支持in-place模式的，此時需要進行table copy(ALGORITHM=COPY).

添加刪除外鍵：

ALTER TABLE tbl1 ADD CONSTRAINT fk_name FOREIGN KEY index (col1) REFERENCES tbl2(col2) referential_actions;

ALTER TABLE tbl DROP FOREIGN KEY fk_name;

當foreign_key_checks參數為disable時，創建外鍵是online的。刪除外鍵時，與該參數的取值無關，都是online狀態的。

刪除外鍵和索引：

ALTER TABLE table DROP FOREIGN KEY constraint, DROP INDEX index;

當外鍵已經作用於正在被修改的表時，進行online DDL會存在一些額外的限制：

如果在子表上進行alter table操作，當存在ON UPDATE或者使用了CASCADE和SET NULL參數的ON DELETE子句時，導致子表的數據隨著父表進行變化，

那麽子表上的alter table語句要等待父表上的事務commit，同理，在父表上進行alter table操作，也要等待子表上的相關事務commit。

因為在進行DDL操作時，對表的讀寫操作不會受到影響，所以提高了應用的響應效率。

由於in-place操作不需要rebuild table，所以節省了磁盤IO和cpu的開銷，最小化了數據庫的負載，在執行DDL期間提供了較好的性能。

相對於copy table，in-place操作只是將較少的數據讀入到buffer pool中，避免了將頻繁使用的數據從buffer pool中沖走，在以前版本，進行DDL操作會導致系統性能降低。

Online DDL的locking選項

通過lock子句強制使用更嚴格的鎖模式，如果lock子句指定鎖的嚴格程度低於某些DDL的最低鎖嚴格程度，那麽多將會報錯，

LOCK=NONE:

允許並發查詢和DML

LOCK=SHARED:

允許並發查詢，但是阻塞DML

LOCK=DEFAULT:

盡量滿足最大並發，如果沒有指定lock子句，默認為此模式

LOCK=EXCLUSIVE:

阻塞並發查詢和DML

當主要關心的是在盡可能短的時間內完成DDL，而並發查詢和DML的執行不重要的情況下，使用此模式

在大多數情況，在表上的online DDL操作會等待當前正在訪問該表的事務commit或rollback，因為當DLL語句正在準備的時候，需要對表進行短暫的排他訪問。

同理online DDL在完成之前需要對表進行一個短暫的排他訪問。所以，如果運行在該表上的事務執行時間過長，那麽會導致online DDL等待排他訪問超時。

未完待續

本博客剛剛開通，旨在將本人的工作和學習經驗在此分享，因為之前的資料雜亂無章，過於零碎，所以整理的時間會長一些，很多地方也沒有描述清楚，在後續過程中會進一步整理。

MySQL Online DDL詳解