對於Online DDL，之前簡單分析了一些場景MySQL中的Online DDL(第一篇）(r11筆記第3天)，其實有一個很關鍵的點沒提到，那就是online DDL的演算法，目前有三個操作選項，default,inplace,copy可選

具體可以參考 https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.html

> select count(*) from newtest;
+----------+
| count(*) |
+----------+
| 22681426 |
+----------+
1 row in set (45.76 sec)表結構資訊如下：

> show create table newtest\G
*************************** 1. row ***************************
Table: newtest
Create Table: CREATE TABLE `newtest` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`game_type` int(11) NOT NULL DEFAULT '-1' ,
`login_time` datetime NOT NULL DEFAULT '1970-01-01 00:00:00',
`login_account` varchar(100) DEFAULT NULL ,
`cn_master` varchar(100) NOT NULL DEFAULT '' ,
`client_ip` varchar(100) DEFAULT '' ,
PRIMARY KEY (`id`),
KEY `ind_tmp_account1` (`login_account`),
KEY `ind_login_time_newtest` (`login_time`)
) ENGINE=InnoDB AUTO_INCREMENT=22681850 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

預設的copy選項

比如我們執行下面的SQL,新增一個欄位，預設情況下是使用copy的演算法，即資料是平行復制一份。

alter table newtest add column newcol varchar(10) default '';這個變更過程會生成兩個臨時的檔案.frm,.ibd
-rw-r----- 1 mysql mysql       8840 Dec 5 18:13 newtest.frm
-rw-r----- 1 mysql mysql 4353687552 Dec 5 18:45 newtest.ibd
...
-rw-r----- 1 mysql mysql       8874 Feb 27 22:25 #sql-6273_2980ab.frm
-rw-r----- 1 mysql mysql   41943040 Feb 27 22:25 #sql-ib280-3638407428.ibd
...在這個變更的過程中，是執行DML操作的，而且沒有任何阻塞。

> insert into newtest(game_type,login_time,login_account,cn_master,client_ip) values(1,'2017-02-27 16:22:10','150581500032','572031626','183.128.143.113');
Query OK, 1 row affected (0.05 sec)

因為使用了主鍵自增，所以我可以用同樣的語句再插入一條記錄，也是全然沒有阻塞。

> insert into newtest(game_type,login_time,login_account,cn_master,client_ip) values(1,'2017-02-27 16:22:10','150581500032','572031626','183.128.143.113');
Query OK, 1 row affected (0.00 sec)這個時候檢視show processlist的結果，相比就顯得有些簡單了。不像之前的版本中會有table metadata lock的字樣了。

對比臨時檔案和現有配置檔案

我們簡單看看上面列舉出來的配置檔案.frm

可以透過strings的方式看到一個基本的結構資訊。

# strings newtest.frm
PRIMARY
ind_tmp_account1
ind_login_time_newtest
InnoDB
)
game_type
login_time
login_account
cn_master
client_ip
game_type
login_time
login_account
cn_master
client_ip
而檢視臨時建立的.frm檔案

# strings "#sql-6273_2980ab.frm"
PRIMARY
ind_tmp_account1
ind_login_time_newtest
InnoDB
)
game_type
login_time
login_account
cn_master
client_ip
newcol
game_type
login_time
login_account
cn_master
client_ip
newcol整個新增欄位的操作持續時間為10分鐘左右。

> alter table newtest add column newcol varchar(10) default '';
Query OK, 0 rows affected (10 min 31.64 sec)
Records: 0 Duplicates: 0 Warnings: 0可以看到修改後的.ibd檔案大小相比要大了一些。

-rw-r----- 1 mysql mysql 8874 Feb 27 22:25 newtest.frm
-rw-r----- 1 mysql mysql 4047503360 Feb 27 22:34 newtest.ibd而如果我們換一個角度來看，我們刪除一個欄位。

--alter table newtest drop column newcol , ALGORITHM=INPLACE; --這種方式是有問題的，採用如下的方式，我們宣告使用inplace演算法，而實際情況如何呢。

> alter table newtest drop column newcol , ALGORITHM=INPLACE;
Query OK, 0 rows affected (9 min 54.18 sec)
Records: 0 Duplicates: 0 Warnings: 0我們可以看到DML操作暢通無阻。

> insert into newtest(game_type,login_time,login_account,cn_master,client_ip) values(1,'2017-02-27 16:22:10','150581500032','572031626','183.128.143.113');
Query OK, 1 row affected (0.15 sec)這個過程可以看到效果和啟用copy演算法是一樣的，為什麼呢。因為新增欄位，刪除欄位是一個資料重組的過程，所以相比而言，這個操作的代價也是昂貴的。

新增/刪除索引

然後我們新增索引，啟用inplace演算法。

alter table newtest add index (client_ip) ,algorithm=inplace;這個過程就特別了，依舊會建立.frm的臨時檔案，但是資料檔案不會複製，而是現改。
-rw-r----- 1 mysql mysql 8840 Feb 27 22:49 newtest.frm
-rw-r----- 1 mysql mysql 4018143232 Feb 27 23:06 newtest.ibd
...
-rw-r----- 1 mysql mysql 8840 Feb 27 23:06 #sql-6273_2980ab.frm這個過程中，DML依舊是暢通的。

> insert into newtest(game_type,login_time,login_account,cn_master,client_ip) values(1,'2017-02-27 16:22:10','150581500032','572031626','183.128.143.113');
Query OK, 1 row affected (0.04 sec)整個新增的過程相比而言，持續時間要短很多，大概是3分鐘左右。

> alter table newtest add index (client_ip) ,algorithm=inplace;
Query OK, 0 rows affected (3 min 42.84 sec)
Records: 0 Duplicates: 0 Warnings: 0
而如果此時刪除索引，這個過程就如同非一般的感覺，不到一秒即可完成。

> alter table newtest drop index client_ip ,algorithm=inplace;
Query OK, 0 rows affected (0.13 sec)
Records: 0 Duplicates: 0 Warnings: 0整個過程中.frm和.ibd檔案沒有任何大小變化。

-rw-r----- 1 mysql mysql 8840 Feb 27 23:13 newtest.frm
-rw-r----- 1 mysql mysql 4785700864 Feb 27 23:13 newtest.ibd而如果我們為了對比同樣的inpalce和copy操作場景下的代價，可以使用copy顯示建立一個索引，即可得到一個基本的對比情況。

alter table newtest add index (client_ip) ,algorithm=copy;整個過程因為.ibd檔案較大，持續時間也會放大很多，這個環境中執行時間是29分,差別已然非常明顯。

> alter table newtest add index (client_ip) ,algorithm=copy;
Query OK, 22681430 rows affected (29 min 13.80 sec)
Records: 22681430 Duplicates: 0 Warnings: 0

小結

Online DDL還是存在著一些限定情況，很多場景還沒有完全測試到，需要結合具體的場景和需求來考量。

MySQL Online DDL（二）（r11筆記第88天）

相關文章