目錄問(wèn)題描述MySQL Online DDL加列的歷史方法01 Copy方法02 Inplace方法MySQL8.0.12 引入的Instant方法問(wèn)題描述

前幾天同事問(wèn)了我一個(gè)問(wèn)題：業(yè)務(wù)A從MySQL遷移到MongoDB的原因是什么？

說(shuō)實(shí)話，這個(gè)問(wèn)題還真不好回答，為什么要遷移，一定是遇到了某種瓶頸，可能是數(shù)據(jù)量也可能是數(shù)據(jù)類型等，于是我咨詢了一下業(yè)務(wù)，最終得到了答案：這個(gè)業(yè)務(wù)中的某些表，要頻繁的加字段。mongodb中加字段的成本幾乎沒(méi)有，而MySQL低版本中加字段的成本還是挺高的。

那么常用的MySQL添加字段的方法有哪些呢？這里我簡(jiǎn)單列舉一下：

1、percona的pt-osc工具

2、github開(kāi)源項(xiàng)目gh-ost工具

3、MySQL原生Online DDL

MySQL Online DDL加列的歷史方法01 Copy方法

MySQL5.5版本及之前的加列方法：Copy

它的執(zhí)行示意圖如下：

我們有一個(gè)原表A，只包含1個(gè)字段，它包含1、2、4、6這幾條記錄，當(dāng)我們使用Copy算法加列時(shí)：

1、創(chuàng)建了一個(gè)新的表tmp-A，新表包含2個(gè)字段，

2、然后我們把表A的數(shù)據(jù)全部逐行拷貝到tmp-A這個(gè)新表里面，

3、然后用tmp-A表和A表做個(gè)交換，

這樣，我們的新表就包含2個(gè)字段了。同時(shí)需要注意，新表中的數(shù)據(jù)記錄比原表更加緊湊了。原表中可能由于刪除了3和5兩條記錄，使得表中間留下了空洞，或者叫空間碎片。

可以看到，Copy算法需要拷貝一遍數(shù)據(jù)，需要額外的存儲(chǔ)空間來(lái)存儲(chǔ)tmp-A這個(gè)臨時(shí)表。另外，在拷貝數(shù)據(jù)的過(guò)程中，表A的寫入操作會(huì)丟失，也就是說(shuō)，表A在alter table的過(guò)程中不能有數(shù)據(jù)更新。這可能是一個(gè)致命的缺點(diǎn)。

02 Inplace方法

MySQL5.6版本開(kāi)始引入Online DDL，這個(gè)功能使得上面的過(guò)程變成了下面這樣：

它的過(guò)程和上面的Copy算法有些不同：

1、Online DDL過(guò)程中，從表A提取B+樹(shù)，并存儲(chǔ)到一個(gè)中間文件tmp-file，而不是中間表tmp-A

2、步驟1執(zhí)行過(guò)程中，對(duì)表A的寫入，都會(huì)記錄到row log中

3、步驟1執(zhí)行完畢后，對(duì)tmp-file應(yīng)用所有的row log，得到一個(gè)與表A數(shù)據(jù)相同的數(shù)據(jù)文件

4、利用數(shù)據(jù)文件tmp-file替換表A的數(shù)據(jù)文件即可。

這個(gè)過(guò)程中，由于row log的存在，使得在整個(gè)該表過(guò)程中，表A是可以進(jìn)行增刪改查的操作的，因?yàn)檫@些操作不會(huì)丟失。這也就是為什么把這個(gè)過(guò)程叫做Online DDL的原因。

另外，這里需要解釋下，Copy算法中生成的tmp-A臨時(shí)表是在Server層面創(chuàng)建的，而上述Online DDL操作中的tmp-file是在插件式存儲(chǔ)引擎Innodb內(nèi)部生成的，我們把這種在Innodb內(nèi)部完成的變更操作，稱之為Inplace（中文表示原地），也就是不需要將數(shù)據(jù)挪動(dòng)到'server層的臨時(shí)表'。

MySQL8.0.12 引入的Instant方法

MySQL8.0.12版本引入了Instant的方法，它讓加列變得更加簡(jiǎn)單。instant算法添加列時(shí)不再需要 rebuild 整個(gè)表，只需要在表的 metadata 中記錄新增列的基本信息即可。

我們來(lái)看它的優(yōu)勢(shì)，首先我們創(chuàng)建一個(gè)表t1，并插入26w條數(shù)據(jù)，然后分別添加數(shù)據(jù)列col_1,col_2,col_3,并顯示指定加列的算法為copy、inplace、和instant，結(jié)果如下：

[test] 23:42:45> select count(1) from t1; +----------+ | count(1) | +----------+ | 262144 | +----------+ 1 row in set (0.06 sec) 方案一：copy[test] 23:43:29> alter table t1 add col_1 int,algorithm=copy; Query OK, 262144 rows affected (1.48 sec)Records: 262144 Duplicates: 0 Warnings: 0方案二：inplace[test] 23:43:46> alter table t1 add col_2 int,algorithm=inplace; Query OK, 0 rows affected (0.58 sec)Records: 0 Duplicates: 0 Warnings: 0方案三：instant[test] 23:44:08> alter table t1 add col_3 int,algorithm=instant; Query OK, 0 rows affected (0.01 sec)Records: 0 Duplicates: 0 Warnings: 0m5480:mysqlha_common@10.41.28.124 [test] 23:44:14> show create table t1G*************************** 1. row *************************** Table: t1Create Table: CREATE TABLE `t1` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(10) COLLATE utf8mb4_general_ci DEFAULT NULL, `age` int DEFAULT NULL, `score` int DEFAULT NULL, `col_1` int DEFAULT NULL, `col_2` int DEFAULT NULL, `col_3` int DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_sco` (`score`)) ENGINE=InnoDB AUTO_INCREMENT=458730 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci1 row in set (0.01 sec)

從結(jié)果不難看出，執(zhí)行時(shí)間上：

copy> inplace > instant

與此同時(shí)，copy算法的受影響行數(shù)是全部表，而inplace和instant的算法影響的行數(shù)都是0，說(shuō)明他們是Online DDL操作。

最后，我們還可以通過(guò)下面的方法查看instant列的信息：

[test] 23:53:01> SELECT * FROM information_schema.innodb_tables where name like ’test/t1’G *************************** 1. row *************************** TABLE_ID: 1079 NAME: test/t1 FLAG: 33N_COLS: 10 SPACE: 22 ROW_FORMAT: Dynamic ZIP_PAGE_SIZE: 0 SPACE_TYPE: Single INSTANT_COLS: 61 row in set (0.00 sec)

可以看到，test.t1這個(gè)表的instant列序號(hào)是6，代表它是這個(gè)表的第7個(gè)列(列編號(hào)從0開(kāi)始)。

當(dāng)然，instant算法不支持刪除普通列、無(wú)法設(shè)置列的順序、還有一些其他的限制，詳情可以查看官方文檔：https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html

但這些限制并不影響它成為一個(gè)優(yōu)秀的DDL功能。 相信通過(guò)MySQL版本的不斷迭代，在后面的版本中，有更多的變更操作可以用到instant這種高效的算法。

以上就是MySQL 8.0 Online DDL快速加列的相關(guān)總結(jié)的詳細(xì)內(nèi)容，更多關(guān)于MySQL DDL快速加列的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！