关于MySQL Online DDL

1. Online DDL

在 MySQL 5.1 （带InnoDB Plugin）和5.5中，有个新特性叫 Fast Index Creation（下称 FIC），就是在添加或者删除二级索引的时候，能够不用复制原表。对于以前的版本对于索引的添加删除这类DDL操做，MySQL数据库的操做过程为以下：

1. 首先新建Temp table，表结构是 ALTAR TABLE 新定义的结构
2. 而后把原表中数据导入到这个Temp table
3. 删除原表
4. 最后把临时表rename为原来的表名

为了保持数据的一致性，中间复制数据（Copy Table）全程锁表只读，若是有写请求进来将没法提供服务，链接数爆张。

引入FIC以后，建立二级索引时会对原表加上一个S锁，建立过程不须要重建表（no-rebuild）；删除InnoDB二级索引只须要更新内部视图，并标记这个索引的空间可用，去掉数据库元数据上该索引的定义便可。这个过程也只容许读操做，不能写入，但大大加快了修改索引的速度（不含主键索引，InnoDB IOT的特性决定了修改主键依然须要 Copy Table ）。

FIC只对索引的建立删除有效，MySQL 5.6 Online DDL把这种特性扩展到了添加列、删除列、修改列类型、列重命名、设置默认值等等，实际效果要看所使用的选项和操做类别来定。

1.1 Online DDL选项

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语句不支持对该表的继续写入，则会提示失败，而不会直接发到库上执行。ALGORITHM=COPY默认LOCK级别
• 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以前确保没有大事务在执行，不然同样出现连环锁表。

1.2 考虑不一样的DDL操做类别

从上面的介绍能够看出，不是5.6支持在线ddl就能够为所欲为的alter table，锁不锁表要看状况：

提示：下表根据官方 Summary of Online Status for DDL Operations 整理挑选的经常使用操做。

• In-Place 为Yes是优选项，说明该操做支持INPLACE
• Copies Table 为No是优选项，由于为Yes须要重建表。大部分状况与In-Place是相反的
• Allows Concurrent DML? 为Yes是优选项，说明ddl期间表依然可读写，能够指定 LOCK=NONE（若是操做容许的话mysql自动就是NONE）
• Allows Concurrent Query? 默认全部DDL操做期间都容许查询请求，放在这只是便于参考
• Notes 会对前面几列Yes/No带 * 号的限制说明

Operation	In-Place?	Copies Table?	Allows Concurrent DML?	Allows Concurrent Query?	Notes
添加索引	Yes*	No*	Yes	Yes	对全文索引的一些限制
删除索引	Yes	No	Yes	Yes	仅修改表的元数据
OPTIMIZE TABLE	Yes	Yes	Yes	Yes	从 5.6.17开始使用ALGORITHM=INPLACE，固然若是指定了old_alter_table=1或mysqld启动带--skip-new则将仍是COPY模式。若是表上有全文索引只支持COPY
对一列设置默认值	Yes	No	Yes	Yes	仅修改表的元数据
对一列修改auto-increment 的值	Yes	No	Yes	Yes	仅修改表的元数据
添加 foreign key constraint	Yes*	No*	Yes	Yes	为了不拷贝表，在约束建立时会禁用foreign_key_checks
删除 foreign key constraint	Yes	No	Yes	Yes	foreign_key_checks 不影响
改变列名	Yes*	No*	Yes*	Yes	为了容许DML并发, 若是保持相同数据类型，仅改变列名
添加列	Yes*	Yes*	Yes*	Yes	尽管容许 ALGORITHM=INPLACE ，但数据大幅重组，因此它仍然是一项昂贵的操做。当添加列是auto-increment，不容许DML并发
删除列	Yes	Yes*	Yes	Yes	尽管容许 ALGORITHM=INPLACE ，但数据大幅重组，因此它仍然是一项昂贵的操做
修改列数据类型	No	Yes*	No	Yes	修改类型或添加长度，都会拷贝表，并且不容许更新操做
更改列顺序	Yes	Yes	Yes	Yes	尽管容许 ALGORITHM=INPLACE ，但数据大幅重组，因此它仍然是一项昂贵的操做
修改ROW_FORMAT  和KEY_BLOCK_SIZE	Yes	Yes	Yes	Yes	尽管容许 ALGORITHM=INPLACE ，但数据大幅重组，因此它仍然是一项昂贵的操做
设置列属性NULL 或NOT NULL	Yes	Yes	Yes	Yes	尽管容许 ALGORITHM=INPLACE ，但数据大幅重组，因此它仍然是一项昂贵的操做
添加主键	Yes*	Yes	Yes	Yes	尽管容许 ALGORITHM=INPLACE ，但数据大幅重组，因此它仍然是一项昂贵的操做。 若是列定义必须转化NOT NULL，则不容许INPLACE
删除并添加主键	Yes	Yes	Yes	Yes	在同一个 ALTER TABLE 语句删除就主键、添加新主键时，才容许inplace；数据大幅重组,因此它仍然是一项昂贵的操做。
删除主键	No	Yes	No	Yes	不容许并发DML，要拷贝表，并且若是没有在同一 ATLER TABLE 语句里同时添加主键则会收到限制
变动表字符集	No	Yes	No	Yes	若是新的字符集编码不一样，重建表

从表看出，In-Place为No，DML必定是No，说明 ALGORITHM=COPY 必定会发生拷贝表，只读。但 ALGORITHM=INPLACEE 也要可能发生拷贝表，但能够并发DML:

• 添加、删除列，改变列顺序
• 添加或删除主键
• 改变行格式ROW_FORMAT和压缩块大小KEY_BLOCK_SIZE
• 改变列NULL或NOT NULL
• 优化表OPTIMIZE TABLE
• 强制 rebuild 该表

不容许并发DML的状况有：修改列数据类型、删除主键、变动表字符集，即这些类型操做ddl是不能online的。

另外，更改主键索引与普通索引处理方式是不同的，主键即汇集索引，体现了表数据在物理磁盘上的排列，包含了数据行自己，须要拷贝表；而普通索引经过包含主键列来定位数据，因此普通索引的建立只须要一次扫描主键便可，并且是在已有数据的表上创建二级索引，更紧凑，未来查询效率更高。

修改主键也就意味着要重建全部的普通索引。删除二级索引更简单，修改InnoDB系统表信息和数据字典，标记该因此不存在，标记所占用的表空间能够被新索引或数据行从新利用。

1.3 在线DDL的限制

• 在alter table时，若是涉及到table copy操做，要确保 datadir 目录有足够的磁盘空间，可以放的下整张表，由于拷贝表的的操做是直接在数据目录下进行的。
• 添加索引无需table copy，但要确保 tmpdir 目录足够存下索引一列的数据（若是是组合索引，当前临时排序文件一合并到原表上就会删除）
• 在主从环境下，主库执行alter命令在完成以前是不会进入binlog记录事件，若是容许dml操做则不影响记录时间，因此期间不会致使延迟。然而，因为从库是单个SQL Thread按顺序应用relay log，轮到ALTER语句时直到执行完才能下一条，因此从库会在master ddl完成后开始产生延迟。（pt-osc能够控制延迟时间，因此这种场景下它更合适）
• During each online DDL ALTER TABLE statement, regardless of the LOCK clause, there are brief periods at the beginning and end requiring an exclusive lock on the table (the same kind of lock specified by the LOCK=EXCLUSIVE clause). Thus, an online DDL operation might wait before starting if there is a long-running transaction performing inserts, updates, deletes, or SELECT … FOR UPDATE on that table; and an online DDL operation might wait before finishing if a similar long-running transaction was started while the ALTER TABLE was in progress.
• 在执行一个容许并发DML在线 ALTER TABLE时，结束以前这个线程会应用 online log 记录的增量修改，而这些修改是其它thread里产生的，因此有可能会遇到重复键值错误 (ERROR 1062 (23000): Duplicate entry)。
• 涉及到table copy时，目前尚未机制限制暂停ddl，或者限制IO阀值
  在MySQL 5.7.6开始可以经过 performance_schema 观察alter table的进度
• 通常来讲，建议把多个alter语句合并在一块儿进行，避免屡次table rebuild带来的消耗。可是也要注意分组，好比须要copy table和只需inplace就能完成的，应该分两个alter语句。
• 若是DDL执行时间很长，期间又产生了大量的dml操做，以致于超过了 innodb_online_alter_log_max_size 变量所指定的大小，会引发 DB_ONLINE_LOG_TOO_BIG 错误。默认为 128M，特别对于须要拷贝大表的alter操做，考虑临时加大该值，以此得到更大的日志缓存空间
• 执行完 ALTER TABLE 以后，最好 ANALYZE TABLE tb1 去更新索引统计信息

2. 实现过程

online ddl主要包括3个阶段，prepare阶段，ddl执行阶段，commit阶段，rebuild方式比no-rebuild方式实质多了一个ddl执行阶段，prepare阶段和commit阶段相似。下面将主要介绍ddl执行过程当中三个阶段的流程。

• Prepare阶段 :

  1. 建立新的临时frm文件(与InnoDB无关)
  2. 持有EXCLUSIVE-MDL锁，禁止读写
  3. 根据alter类型，肯定执行方式(copy,online-rebuild,online-norebuild)
     假如是Add Index，则选择online-norebuild即INPLACE方式
  4. 更新数据字典的内存对象
  5. 分配row_log对象记录增量(仅rebuild类型须要)
  6. 生成新的临时ibd文件(仅rebuild类型须要)

• ddl执行阶段 :

  1. 降级EXCLUSIVE-MDL锁，容许读写
  2. 扫描old_table的汇集索引每一条记录rec
  3. 遍历新表的汇集索引和二级索引，逐一处理
  4. 根据rec构造对应的索引项
  5. 将构造索引项插入sort_buffer块排序
  6. 将sort_buffer块更新到新的索引上
  7. 记录ddl执行过程当中产生的增量(仅rebuild类型须要)
  8. 重放row_log中的操做到新索引上(no-rebuild数据是在原表上更新的)
  9. 重放row_log间产生dml操做append到row_log最后一个Block

• commit阶段 :

1. 当前Block为row_log最后一个时，禁止读写，升级到EXCLUSIVE-MDL锁
2. 重作row_log中最后一部分增量
3. 更新innodb的数据字典表
4. 提交事务(刷事务的redo日志)
5. 修改统计信息
6. rename临时idb文件，frm文件
7. 变动完成

3. Online DDL 的思惟导向图

4. Online DDL 注意事项：

• 磁盘空间
  • rebuild 的时候，datadir空间是否足够
    • 由于会拷贝ibd文件，因此要确保空间足够
  • rebuild 的时候，innodb_online_alter_log_max_size是否足够
    • rebuild过程当中，产生的DML涉及到行记录变动日志，是否足够存储
  • inplace的时候，考虑tmpdir空间是否足够
• ddl对从库延迟的影响是否能够接受
  • 主库online DDL的过程当中，因为没有commit，因此其余并发操做能够正常同步到从库
  • 主库commit后，DDL同步到从库
  • 因为从库是单线程执行SQL_THREAD，假设DDL执行过程须要1个小时，那么从库将会滞后1小时+
  • 是否容许从库的滞后，若是不容许，能够经过并行复制来优化处理
• row-log会检查重复值或者修改冲突吗？
  • 会根据主键及惟一约束来检查
• copy table ，inplace下如何暂停DDL操做
  • show full processlist;
  • kill id; #( DDL SQL的id号)
  • 这里kill完后，仍然能够再次正常执行DDL，不会存在冲突，其建立的临时idb及frm文件会自动删除
• copy table ，inplace下宕机
  • 这两种状况下宕机后，没有完成的DDL语句不会继续执行
  • 可是，其生成的frm跟idb临时文件不会被删除，能够手动删除，也能够不手动删除，即便不删除，也不会影响再次执行DDL
  • 但建议mysql服务后，删除无用的临时文件
• 同个表格多个DDL语句，不要一个个执行
• 请按照是否支持inplace及是否须要rebuild分类合并执行

5. 5.7 的版本Online DDL 能够经过P_S 查看进度

1、打开功能

mysql> UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'stage/innodb/alter%'; Query OK, 7 rows affected (0.00 sec) Rows matched: 7 Changed: 7 Warnings: 0 mysql> UPDATE setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%stages%'; Query OK, 3 rows affected (0.00 sec) Rows matched: 3 Changed: 3 Warnings: 0 

2、执行改表操做

mysql> ALTER TABLE employees.employees ADD COLUMN middle_name varchar(14) AFTER first_name; Query OK, 0 rows affected (9.27 sec) Records: 0 Duplicates: 0 Warnings: 0 

3、查看改表进度

mysql> SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM events_stages_current; +------------------------------------------------------+----------------+----------------+ | EVENT_NAME | WORK_COMPLETED | WORK_ESTIMATED | +------------------------------------------------------+----------------+----------------+ | stage/innodb/alter table (read PK and internal sort) | 280 | 1245 | +------------------------------------------------------+----------------+----------------+ 1 row in set (0.01 sec)