1 copy offline（非真正在线ddl）

不能与dml并行，service层新建临时表，copy到临时表

2 inplace online

在引擎层完成，不需要在service层新建临时表。
rebuild：需要重建表，会在原表 路径下新建 .frm 和 .ibd 文件，在 innodb 层完成数据拷贝和表交换。
no-rebuild：不需要重建表，除创建添加索引，会产生部分二级索引的 写入操作外，其余操作均只修改元数据项。

3 inplace but offline

虽然是替换，但是不能并行DML

4 inplace online —rebuild原理

4.1 prepare阶段

1 用户指定的 ALGORITHM 和 LOCK 确定执行期间允许的并发数，然后会获取一个 shared metadata lock(不允许ddl)，用来保护表的结构定义
2 ddl阶段
完成数据拷贝，读取row log增量数据，增量也拷贝
3 commit阶段
对旧表加锁，并重放后一个 block dml 到新表，表交换，完成ddl，

5 原生ddl的问题

DDL 执行的开始和结束时会对表加锁，如果此时表上存 在锁，则会导致 DDL 之后 SQL 等待锁，这是所有 DDL 操 作的通病。并且进行切换前需要加锁回放 DML，也会降低写入性能。
在 MySQL 当前的主从复制架构中，从库回放 DDL 操 作时具有排他性。也就是说，从库回放 DDL 时，只有在该DDL 操作回放完成后，才能回放后续的 DML。如果 DDL 操
作需要花费 1 小时，那么主从复制延迟至少为 1 小时。

6 业界解决方案

1、MySQL 原生的 Online DDL —无法覆盖全部场景
2、Facebook OSC、percona pt-online-schema-change
3、Github 开源的 gh-ost 工具

percona pt-osc 在变更期间会增加对主库的压力。gh-ost 较为灵活，对性能损耗低， 采用此方案。

7 gh-ost 原理

https://www.cnblogs.com/zhoujinyi/p/9187421.html
http://mysql.taobao.org/monthly/2018/05/02/

8 pt-osc 和 gh-ost

pt-osc 和 gh-ost 对比后主要有以下缺点：
1、触发器是用存储过程的实现的，就无法避免存储过程本身需要的开销。
2、增大了同一个事务的执行步骤，更多的锁争抢。
3、整个过程无法暂停，假如发现影响主库性能，停止 Online DDL，那么下次
就需要从头来过。
4、无法灵活的控制 DDL 执行时的参数。