MySQL DDL詳情揭露

前言：

MySQL中DDL語句，即數據定義語言，用於創建、刪除、修改、庫或表結構，對數據庫或表的結構操作。常見的有create，alter，drop等。這類語句通常會耗費很大代價，特別是對於大表做表結構變更。本篇文章會揭露各類DDL語句執行的詳細情況。

1.Online DDL簡介

在MySQL的早期版本中，DDL操作因為鎖表會和DML操作發生鎖沖突，大大降低並發性。在早期版本中，大部分DDL操作的執行原理就是通過重建表的方式，因為要復制原表數據，所以會長時間鎖表，只能讀不能寫，DDL操作和DML操作有很嚴重的沖突。從MySQL5.6開始，很多DDL操作過程都進行了改進，出現了Online DDL，用於支持DDL執行期間DML語句的並行操作，提高數據庫的吞吐量。

MySQL 在線DDL分為 INPLACE 和 COPY 兩種方式，通過在ALTER語句的ALGORITHM參數指定。

• ALGORITHM=INPLACE，可以避免重建表帶來的IO和CPU消耗，保證ddl期間依然有良好的性能和並發。
• ALGORITHM=COPY，需要拷貝原始表，所以不允許並發DML寫操作，可讀。這種copy方式的效率還是不如 inplace ，因為前者需要記錄undo和redo log，而且因為臨時占用buffer pool引起短時間內性能受影響。

上面只是 Online DDL 內部的實現方式，此外還有 LOCK 選項控制是否鎖表，根據不同的DDL操作類型有不同的表現：默認MySQL盡可能不去鎖表，但是像修改主鍵這樣的昂貴操作不得不選擇鎖表。

• LOCK=NONE，即DDL期間允許並發讀寫涉及的表，比如為了保證 ALTER TABLE 時不影響用戶注冊或支付，可以明確指定，好處是如果不幸該 alter語句不支持對該表的繼續寫入，則會提示失敗，而不會直接發到庫上執行。
• LOCK=SHARED，即DDL期間表上的寫操作會被阻塞，但不影響讀取。
• LOCK=DEFAULT，讓mysql自己去判斷lock的模式，原則是mysql盡可能不去鎖表
• LOCK=EXCLUSIVE，即DDL期間該表不可用，堵塞任何讀寫請求。如果你想alter操作在最短的時間內完成，或者表短時間內不可用能接受，可以手動指定。

但是有一點需要說明，無論任何模式下，Online DDL開始之前都需要一個短時間排它鎖(exclusive)來准備環境，所以alter命令發出后，會首先等待該表上的其它操作完成，在alter命令之后的請求會出現等待waiting meta data lock。同樣在DDL結束之前，也要等待alter期間所有的事務完成，也會堵塞一小段時間。所以盡量在ALTER TABLE之前確保沒有大事務在執行，否則一樣出現連環鎖表。

2.不同類DDL操作詳情

不同種類DDL語句具體的執行情況是不同的，下表列舉出常見DDL語句具體的執行詳情，包括是否允許讀寫及是否鎖表。這個表格希望大家可以詳細對比看下，特別要關注下需要copy table的DDL操作。

操作	支持方式	Allow R/W	說明
add/create index	online	允許讀寫	當表上有FULLTEXT索引除外，需要鎖表，阻塞寫
drop index	online	允許讀寫	操作元數據，不涉及表數據。所以很快，可以放心操作
optimize table	online	允許讀寫	當帶有fulltext index的表用copy table方式並且阻塞寫
alter table...engine=innodb	online	允許讀寫	當帶有fulltext index的表用copy table方式並且阻塞寫
add column	online	允許讀寫(增加自增列除外)	1、添加auto_increment列要鎖表，阻塞寫;2、雖采用online方式，但是表數據需要重新組織，所以增加列依然是昂貴的操作
drop column	online	允許讀寫(增加自增列除外)	同add column，重新組織表數據，，昂貴的操作
Rename a column	online	允許讀寫	操作元數據;不能改列的類型，否則就鎖表
Reorder columns	online	允許讀寫	重新組織表數據，昂貴的操作
Make column NOT NULL	online	允許讀寫	重新組織表數據，昂貴的操作
Change data type of column	copy table	僅支持讀，阻塞寫	創建臨時表，復制表數據，昂貴的操作
Set default value for a column	online	允許讀寫	操作元數據，因為default value存儲在frm文件中，不涉及表數據。所以很快，可以放心操作
alter table xxx auto_increment=xx	online	允許讀寫	操作元數據，不涉及表數據。所以很快，可以放心操作
Add primary key	online	允許讀寫	昂貴的操作
Convert character set	copy table	僅支持讀，阻塞寫	如果新字符集不同，需要重建表，昂貴的操作

3.DDL最佳實踐

雖然MySQL 5.6和5.7版本提供了Online DDL操作，但Online DDL仍存在以下問題：

• 主從復制延遲，只有主庫上DDL執行成功才會寫入到binlog中，而DDL操作在從庫上不能並發執行，因此即使主庫執行DDL時允許並發DML操作，對於大表操作，仍會引發嚴重的復制延遲。
• 主庫執行Online DDL時，不能根據負載暫停DDL操作。
• 使用Inplace方式執行的DDL，發生錯誤或被KILL時，需要一定時間的回滾期，執行時間越長，回滾時間越長。
• 使用Copy方式執行的DDL，需要記錄過程中的undo和redo日志，同時會消耗buffer pool的資源，效率較低，優點是可以快速停止。
• Online DDL並不是所有時間段的Online，在特定時間段需要加元數據鎖或其他鎖。
• 允許並發DML的DDL，可能會導致Duplicate entry問題。

針對DDL，下面整理下幾點干貨建議，之后執行DDL語句時可以參考下：

1. 執行DDL前查看下該表有沒有被事務占用，防止出現MDL鎖。
2. 執行DDL前確保datadir，tmpdir磁盤空間足夠。
3. 能業務低峰期操作的DDL，都盡量安排在業務低峰期進行。
4. 對於大表和較大表，如果對復制延遲和主庫性能敏感，建議改為gh-ost或pt-osc工具。
5. 對於並發操作較高的表，無論表數據量多少，不能在業務高峰期操作。
6. 同個表的多個DDL語句可以合並在一起進行，避免多次table rebuild帶來的消耗。但是也要注意分組，比如需要copy table和只需inplace就能完成的，應該分兩個alter語句。

參考：

• https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html
• https://www.cnblogs.com/rayment/p/7762520.html