MySQL Online DDL（二）（r11笔记第88天）

对于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的字样了。

+---------+-----------------+-----------------------------+----------------+-------------+---------+--------------------------------
|Id      | User            | Host                        | db             | Command     | Time    | State                          
+---------+-----------------+-----------------------------+----------------+-------------+---------+--------------------------------
| 2719915 | root            | localhost                   | test           | Query       |      75 | altering table

对比临时文件和现有配置文件

咱们简单看看上面列举出来的配置文件.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仍是存在着一些限定状况，不少场景尚未彻底测试到，须要结合具体的场景和需求来考量。