MySQL online DDL的功能就是在对表就行DDL操作的同时也可以对表进行读写操作，

即对表的DDL操作不会影响该表上的事务。

该功能的优点：

改善繁忙生产环境的响应效率和可用性。

可以使用lock子句在性能和并发性之间进行协调。

相比ALGORITHM=COPY算法使用较少的磁盘空间和IO的开销。

使用了ALGORITHM，LOCK子句的onlin DDL:

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

lock子句用于设置DDL执行期间，该表上的并发程度

ALGORITHM=INPLACE and ALGORITHM=COPY子句用于设置online DDL的处理算法，进行DDL时一定要尽量避免出现table copy

DDL online支持总览表：

OperationIn PlaceRebuilds TablePermits Concurrent DMLOnly Modifies MetadataNotes

Yes*

No*

Yes

No

Restrictions apply for FULLTEXT indexes; see next row.

Yes*

No*

No

No

Adding the first FULLTEXT index rebuilds the table if there is no user-defined FTS_DOC_ID column. Subsequent FULLTEXT indexes may be added on the same table without rebuilding the table.

Yes

No

Yes

Yes

Only modifies table metadata.

Yes

No

Yes

Yes

Only modifies table metadata.

Yes*

Yes

Yes

No

In-place operation is not supported for tables with FULLTEXT indexes.

Set column default value

Yes

No

Yes

Yes

Only modifies table metadata.

Yes

No

Yes

No*

Modifies a value stored in memory, not the data file.

Yes*

No

Yes

Yes

The INPLACE algorithm is supported when foreign_key_checks is disabled. Otherwise, only the COPY algorithm is supported.

Yes

No

Yes

Yes

foreign_key_checks can be enabled or disabled.

Rename column

Yes*

No

Yes*

Yes

To permit concurrent DML, keep the same data type and only change the column name. ALGORITHM=INPLACE is not supported for renaming agenerated column.

Add column

Yes*

Yes*

Yes*

No

Concurrent DML is not permitted when adding an auto-increment column. Data is reorganized substantially, making it an expensive operation. ALGORITHM=INPLACE is supported for adding a virtual generated column but not for adding a stored generated column. Adding a virtual generated column does not require a table rebuild.

Drop column

Yes

Yes*

Yes

No

Data is reorganized substantially, making it an expensive operation.ALGORITHM=INPLACE is supported for dropping a generated column. Dropping a virtual generated column does not require a table rebuild.

Reorder columns

Yes

Yes

Yes

No

Data is reorganized substantially, making it an expensive operation.

Change ROW_FORMAT property

Yes

Yes

Yes

No

Data is reorganized substantially, making it an expensive operation.

Change KEY_BLOCK_SIZEproperty

Yes

Yes

Yes

No

Data is reorganized substantially, making it an expensive operation.

Make column NULL

Yes

Yes*

Yes

No

Rebuilds the table in place. Data is reorganized substantially, making it an expensive operation.

Make column NOT NULL

Yes*

Yes

Yes

No

Rebuilds the table in place. STRICT_ALL_TABLES orSTRICT_TRANS_TABLES SQL_MODE is required for the operation to succeed. The operation fails if the column contains NULL values. The server prohibits changes to foreign key columns that have the potential to cause loss of referential integrity. See Section 13.1.8, “ALTER TABLE Syntax”. Data is reorganized substantially, making it an expensive operation.

Change column data type

No*

Yes

No

No

VARCHAR size may be increased using online ALTER TABLE. See Modifying Column Properties for more information.

Yes*

Yes*

Yes

No

Rebuilds the table in place. Data is reorganized substantially, making it an expensive operation.ALGORITHM=INPLACE is not permitted under certain conditions if columns have to be converted to NOT NULL.

Drop primary key and add another

Yes

Yes

Yes

No

Data is reorganized substantially, making it an expensive operation.

No

Yes

No

No

Only ALGORITHM=COPY supports dropping a primary key without adding a new one in the same ALTER TABLEstatement.

Convert character set

No

Yes*

No

No

Rebuilds the table if the new character encoding is different.

Specify character set

No

Yes*

No

No

Rebuilds the table if the new character encoding is different.

Rebuild with FORCE option

Yes*

Yes

Yes

No

Uses ALGORITHM=INPLACE.ALGORITHM=INPLACE is not supported for tables with FULLTEXT indexes.

“null” rebuild using ALTER TABLE ... ENGINE=INNODB

Yes*

Yes

Yes

No

Uses ALGORITHM=INPLACE.ALGORITHM=INPLACE is not supported for tables with FULLTEXT indexes.

Set STATS_PERSISTENT,STATS_AUTO_RECALC,STATS_SAMPLE_PAGESpersistent statistics options

Yes

No

Yes

Yes

Only modifies table metadata.

ALTER TABLE … ENCRYPTION

No

Yes

No

Yes

Drop a STORED column

Yes

Yes*

Yes

No

Rebuilds the table in place.

Modify STORED column order

Yes

Yes*

Yes

No

Rebuilds the table in place.

Add a STORED column

Yes

Yes*

Yes

No

Rebuilds the table in place.

Drop a VIRTUAL column

Yes

No

Yes

Yes

Modify VIRTUAL column order

Yes

No

Yes

Yes

Add a VIRTUAL column

Yes

No

Yes

Yes

常用的online DDL：

创建二级索引：

CREATE INDEX name ON table(col_list);ALTER TABLE table ADD INDEX name (col_list);

删除二级索引：

DROP INDEX name ON table;ALTER TABLE tbl_name DROP INDEX name;

在innodb表上创建和删除二级索引不会产生table-copying

当索引正在被创建或删除时，是可以对表进行读写操作的， 在对表执行create index或drop index语句时，只有在访问该表的事务完成之后，create index和drop index语句才可以完成，所以索引的初始状态反映了表中最新的数据，在以前，对正在执行create index或drop index的表进行操作时，会导致将insert，update，delete操作撤销掉的死锁。

online ddl的另外一个用法是，在进行数据迁移时，可以先创建表结构，然后导入数据，最后创建相关索引，这种方式通常会提高数据迁移的效率。

新创建的二级索引只包含在create index和alter table语句完成时，已经在该表上commit的数据，不包含未提交的值，old version值，已经标记删除的值。

如果在创建二级索引时，MySQL崩溃或是异常宕机，在恢复时，MySQL会drop掉创建了一半的索引，所以此时需要重新手动创建索引。

重命名索引也是online DDL

ALTER TABLE tbl_name RENAME INDEX old_index_name TO new_index_name, ALGORITHM=INPLACE, LOCK=NONE;

创建全文索引：

CREATE FULLTEXT INDEX name ON table(column);

如果在创建第一个全文索引时，如果FTS_DOC_ID列之前没有创建过，那么创建全文索引需要rebuild table，在之后创建全文索引时是online状态的，不需要rebuild table。

添加和删除主键索引：

重建聚集索引总是要进行copy table，所以在建表时一定要设计好主键，尽量在之后使用alter table来修改

只有当sql_mode的设置包含了 strict_trans_tables 或strict_all_tables 标记时， ALGORITHM=INPLACE是允许的

但是创建主键的列包含null值的话，会导致语句执行失败。

如果表中没有主键，innodb会自动选择第一个被定义为not null unique的字段作为主键，或是在内部自动生成一个自动作为主键，但这会有隐藏的空间开销。

MySQL创建新的聚集索引是通过将原表中已存在的数据copy到按照目标索引结构产生的临时表中，在数据copy完成后，将该临时表rename为原来的表的名称，

并将原表从数据库中drop掉。

因为MySQL是索引组织表，表的结构与主键密切相关，所以重定义主键一定会导致copy table，

此时使用ALGORITHM=INPLACE虽然会出现copy table，但仍比ALGORITHM=COPY的效率要高，因为：

不产生undo和redo日志。

二级索引的记录是预先排好序的，所以可以按照顺序导入。

没有使用到change buffer，因为没有随机访问insert到二级索引。

ALTER TABLE tbl_name DROP PRIMARY KEY, ALGORITHM=COPY;

只有ALGORITHM=COPY模式支持drop primary key.

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

数据会大量重组，该操作是一个开销很大操作。

修改字段的属性值：

ALTER TABLE tbl ALTER COLUMN col SET DEFAULTliteral;ALTER TABLE tbl ALTER COLUMN col DROP DEFAULT;

字段的默认值存储在表的.frm文件中，而不是innodb的数据字典中。

修改字段的自增值：

ALTER TABLE table AUTO_INCREMENT=next_value;

在使用复制的分布式系统，或者是分片中，需要重新设置自增值到某一个指定的值，在数据仓库中，有时需要清空表中的数据，然后重置自增值，再导入新的数据。

重命名字段名称：

ALTER TABLE tbl CHANGE old_col_name new_col_name datatype;

当使用该语句只是修改字段的名称，而没有修改字段类型时，该语句的执行总是online的。

在对外键约束中的字段进行重命名后，在外键的定义中会自动将该字段的名称更新为重命名后的名称，对外键中的字段进行重命名操作时，该操作仅运行在 in-place模式，

当在修改语句中指定 ALGORITHM=COPY或者其他因素导致修改语句使用了 ALGORITHM=COPY，那么重命名字段的语句将会执行失败。

使用in-place模式修改varchar字段的长度：

ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(255);

每次修改varchar字段的长度时，varchar内部编码需要的字节长度值一定要保持相同，因为varchar值从0-255时，需要1个字节长度来编码值，当varchar从256字节开始需要2个字节长度来编码值，所以当修改varchar字段的长度时，从0字节增加到255字节，或者从大于等于256字节开始增加长度都是支持in-place模式的，当从一个小于256字节的长度增加到大于256字节的长度，因为此时会导致varchar内部编码值所需要的字节长度从1个字节长度变为2个字节长度，所以此时不能使用in-place模式，只能使用ALGORITHM=COPY模式，例如下述修改varchar长度的语句将会执行失败：

ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256);

ERROR 0A000: ALGORITHM=INPLACE is notsupported. Reason: Cannot changecolumn type INPLACE. Try ALGORITHM=COPY.

缩小varchar字段的长度时不支持in-place模式的，此时需要进行table copy(ALGORITHM=COPY).

添加删除外键：

ALTER TABLE tbl1 ADD CONSTRAINT fk_name FOREIGN KEY index (col1) REFERENCEStbl2(col2) referential_actions;ALTER TABLE tbl DROP FOREIGN KEY fk_name;

当foreign_key_checks参数为disable时，创建外键是online的。删除外键时，与该参数的取值无关，都是online状态的。

删除外键和索引：

ALTER TABLE table DROP FOREIGN KEY constraint, DROP INDEX index;

当外键已经作用于正在被修改的表时，进行online DDL会存在一些额外的限制：

如果在子表上进行alter table操作，当存在ON UPDATE或者使用了CASCADE和SET NULL参数的ON DELETE子句时，导致子表的数据随着父表进行变化，

那么子表上的alter table语句要等待父表上的事务commit，同理，在父表上进行alter table操作，也要等待子表上的相关事务commit。

因为在进行DDL操作时，对表的读写操作不会受到影响，所以提高了应用的响应效率。

由于in-place操作不需要rebuild table，所以节省了磁盘IO和cpu的开销，最小化了数据库的负载，在执行DDL期间提供了较好的性能。

相对于copy table，in-place操作只是将较少的数据读入到buffer pool中，避免了将频繁使用的数据从buffer pool中冲走，在以前版本，进行DDL操作会导致系统性能降低。

Online DDL的locking选项

通过lock子句强制使用更严格的锁模式，如果lock子句指定锁的严格程度低于某些DDL的最低锁严格程度，那么多将会报错，

LOCK=NONE:

允许并发查询和DML

LOCK=SHARED:

允许并发查询，但是阻塞DML

LOCK=DEFAULT:

尽量满足最大并发，如果没有指定lock子句，默认为此模式

LOCK=EXCLUSIVE:

阻塞并发查询和DML

当主要关心的是在尽可能短的时间内完成DDL，而并发查询和DML的执行不重要的情况下，使用此模式

在大多数情况，在表上的online DDL操作会等待当前正在访问该表的事务commit或rollback，因为当DLL语句正在准备的时候，需要对表进行短暂的排他访问。

同理online DDL在完成之前需要对表进行一个短暂的排他访问。所以，如果运行在该表上的事务执行时间过长，那么会导致online DDL等待排他访问超时。

未完待续

本博客刚刚开通，旨在将本人的工作和学习经验在此分享，因为之前的资料杂乱无章，过于零碎，所以整理的时间会长一些，很多地方也没有描述清楚，在后续过程中会进一步整理。