我们之前介绍过Percona出品的pt-online-schema-change工具，它可以实现在线的DDL，其实MySQL在5.6版本中也加入了online DDL的功能，但是由于当时功能的不健，导致DBA们再使用时非常谨慎，甚至直接放弃了MySQL自带的在线变更功能，随着MySQL5.7的不断优化以及8.0的问世，MySQL自带的online DDL也是越发的完善和稳定，今天我们就一起来了解下。
ALGORITHMMySQL online DDL的语法举例，比如我们想新增一个主键：
ALTER TABLE tbl_name ADD PRIMARY KEY (column), ALGORITHM=INPLACE, LOCK=NONE;其中 ALGORITHM 有三种算法，分别是 copy ， inplace ， instant 。
copy：当MySQL选用这种算法时，整个操作是offline的，在DDL执行期间会阻塞其他DML语句，期间会生产临时表，将原表中的数据拷贝至新表中。
inplace：所有的操作都是在innodb引擎层完成，不需要经过临时表。除了创建fulltext索引和spatial索引外，其他场景都是允许DML并行操作的。该算法又根据是否重建表分为rebuild和no-rebuild。
rebuild涉及表的重建，会在原表路径下生成新的.frm和.ibd文件，同时申请row log空间记录DDL执行期间的DML操作记录，最后再DDL提交阶段重做row log中的内容。
no-rebuild不涉及表的重建，除了创建添加索引会产生二级索引的写入操作外，其余操作只修改元数据信息，不会生成.ibd文件，并且不会申请row log空间，这种场景消耗IO较少，速度较快。
instant：该特性是MySQL8.0.12引入，只修改数据字典的元数据信息，无需拷贝数据也无需重建表，原表数据不受影响。整个DDL过程执行非常快，不会阻塞DML操作。
注意：
在执行DDL操作时，一般不需要我们指定ALGORITHM，MySQL内部会自行判断应该采用哪种方式进行变更。
扫描二维码关注公众号，回复： 12735602 查看本文章
对于涉及rebuild表的操作，需要关注下原表所在磁盘的使用情况。
对于申请row log空间的操作，需要关注innodb_online_alter_log_max_size的值，该值默认128M，代表row log的最大值，支持动态修改。空间每次申请的大小由innodb_sort_buffer_size决定。
对于24小时业务表，如果你不确定该操作会不会影响线上业务，建议使用pt-osc工具执行变更。
DDL操作场景分类 前面讲了online ddl的各种算法，由于并不是所有的操作是online的，需要我们加以区分，针对不同的操作MySQL内部会采用哪种模式进行变更，我进行了分类总结，希望能帮助到你！
