Mysql Online DDL的使用詳解

更新時間：2021年05月20日 11:32:44 作者：xmebcc

在日常DBA運維過程中，對表結構進行變更算是個普遍的需求了。如果操作的對象是個熱表、大表，難免心里一怵，這些DDL操作是否可以直接執(zhí)行，哪些會影響線上讀寫，哪些會影響主從，甚至導致服務器壓力驟升，本文做了梳理，希望對大家有所幫助。

正文

Online DDL在MySQL 5.6才開始支持的，在5.5及之前版本，使用alter table/create index等命令進行表結構修改操作均會鎖表，這在生產(chǎn)環(huán)境上明顯是不可接受的。

在MySQL 5.7，Online DDL在性能和穩(wěn)定性上不斷得到優(yōu)化，性能有顯著優(yōu)勢，且對業(yè)務負載影響小，停寫時間可控，相對pt-osc/gh-ost來說，無需安裝第三方依賴包，同時支持Inplace算法的Online DDL，由于無需拷表，所需磁盤空間也更小。

先來看一個常見的DDL語句：

ALTER TABLE tbl_name ADD PRIMARY KEY (column), ALGORITHM=INPLACE, LOCK=NONE;

其中，LOCK描述了DDL期間運行的并發(fā)程度，ALGORITHM描述了DDL的實現(xiàn)方式

LOCK參數(shù)

LOCK=NONE:允許并發(fā)的查詢和DML操作
LOCK=SHARED:允許并發(fā)的查詢，但阻塞DML操作
LOCK=DEFAULT: 由系統(tǒng)決定，允許盡可能多的并發(fā)性(并發(fā)查詢、DML或兩者)。如果省略LOCK子句相當于指定LOCK=DEFAULT
LOCK=EXCLUSIVE:阻塞并發(fā)查詢和DML操作。

ALGORITHM參數(shù)

ALGORITHM=COPY：采用拷表方式進行表變更，與pt-osc/gh-ost類似；
ALGORITHM=INPLACE：僅需要進行引擎層數(shù)據(jù)改動，不涉及Server層；

COPY TABLE流程

首先建立臨時表，表結構為ALTAR TABLE更改后的結構
將原表中數(shù)據(jù)導入到臨時表（server層創(chuàng)建臨時表，會有顯示的IBD文件）
刪除原表
將臨時表rename為原來的表名

同時這一過程中，為了保持數(shù)據(jù)的一致性，中間復制數(shù)據(jù)時（Copy Table）全程鎖表只讀，如果有寫請求進來將無法提供服務，將導致連接數(shù)爆張。

IN-PLACE流程

建立一個臨時文件，掃描原表主鍵的所有數(shù)據(jù)頁
用數(shù)據(jù)頁中原表記錄生成B+樹，存儲到臨時文件中（innodb_temp_data_file_path臨時表空間下創(chuàng)建臨時文件）
生成臨時文件的過程中，將所有對原表的操作記在一個日志文件(rowlog)中
臨時文件生成后，將日志文件中的操作應用到臨時文件，得到一個輯數(shù)據(jù)上與原表相同
數(shù)據(jù)文件（日志文件記錄和重放操作）
用臨時文件替換原表數(shù)據(jù)文件

這一過程中，alter 語句在啟動的時候獲取MDL寫鎖，但是這個寫鎖在真正拷貝數(shù)據(jù)之前就退化成讀鎖，也就是說在最耗時的copy數(shù)據(jù)到臨時文件的過程中，原表是可以進行dml操作的，僅僅會在最后的新舊表切換階段加鎖，這個rename的時間就非?？炝?。

允許并發(fā)DML的DDL操作

創(chuàng)建/新增二級索引
重命名二級索引
刪除二級索引
改變索引類型(USING {BTREE | HASH})
添加主鍵（expensive cost）
刪除主鍵并增加另一個（expensive cost）(ALTER TABLE tbl_name DROP PRIMARY KEY, ADD PRIMARY KEY (column), ALGORITHM=INPLACE, LOCK=NONE;)
新增列（expensive cost）
刪除列（expensive cost）
重命名列
列重新排序（expensive cost）
改變列默認值
刪除列默認值
改變列自增值
設置列屬性null/not null （expensive cost）
修改枚舉或集合列的定義
Change ROW_FORMAT
Change key block size