【MySQL】执行DDL选择Online DDL还是PT-OSC？

1.前言

MySQL DDL（Data Definition Language）表结构变更，主要支持Online DDL和PT-OSC模式，但是即使知道两者的工作原理，在什么情况下选择什么模式新增或者更改mysql的表结构，感觉能完整清楚表述出的文章并不太多。

因此站在巨人的肩膀上，将大佬的总结，进行理解、补充和记录。

以下文章以 MySQL 5.7.24 版本作为讲述依据

官方文档：https://dev.mysql.com/doc/refman/5.7/en/innodb-introduction.html

2.Online DDL和PT-OSC原理、执行机制以及优缺点

在线DDL（Data Definition Language）操作和Percona Toolkit中的pt-online-schema-change工具都是为了在不停机的情况下进行数据库模式更改而设计的，旨在减少或消除对应用程序的影响。

他们的一个显著区别在Online DDL采用数据迁移的方式将原数据逐步迁移到新表中，而PT-OSC采用的是直接复制原表数据

2.1.Online DDL

在线DDL操作利用数据库管理系统（DBMS）内部的机制来实现在服务不中断的情况下修改表结构。这通常通过创建一个新表（具有新的模式），然后在后台将旧表的数据迁移到新表，最后原子性地交换两个表的引用，从而完成模式变更。整个过程对外部查询是透明的，可以继续访问旧数据，直到切换完成。

包含以下几个步骤：

创建新表：创建一个与原表结构相似但包含所需更改的新表。
数据迁移：将原表的数据逐步迁移到新表中。
DML重放：在数据迁移过程中，捕获并重放所有对原表的DML（数据操纵语言）操作，以保持数据一致性。
表交换：完成数据迁移和DML重放后，使用原子操作替换原表和新表的引用，确保客户端无缝过渡到新表。
清理：删除旧表或将其标记为废弃。

优点：

无停机时间：可以在不影响应用服务的情况下进行模式更改。
数据一致性：保证数据在迁移过程中的完整性和一致性。

缺点：

性能影响：在数据迁移期间，可能会影响数据库的写入性能。主要集中在DML重放
资源消耗：需要额外的存储空间来容纳新表。
复制延迟：如果有从库，这有一个很致命的弱点。因为主库执行的动作，会在从库再来一遍，如果这个动作是非常耗时的，那在从库执行（重放主库的动作）的时间点开始，其后续所有动作都被堵塞住，直到从库也执行完这个DDL后，才会继续按顺序执行其他SQL。这就就意味着，从从库执行开始，从库复制就出现了延迟，延迟的时间会慢慢变大，直到DDL执行完后，延迟才会慢慢变小。
特殊情况：云侧MySQL RDS，本身有一个隐藏从库用于高可用，因为这个隐藏从库不对外提供服务，所以基本上业务侧也不需要去关注他。但极端情况，如果大表DDL操作使用Online DDL模式时，在隐藏从库正在执行DDL期间，主库挂了，那常理就需要切换到隐藏从库，才能继续提供服务，但为了保证数据的一致性，隐藏从库必须要等DDL执行完，再回放DDL之后的binlog，然后，才能将其提升为主库，对外提供服务，所以这个恢复时间有可能很长。总得来讲，这个情况对业务而言也是致命的，只不过概率极低。

2.2.PT-OSC

pt-online-schema-change是一个外部工具，它利用自身的算法和技术来实现在线DDL操作，它通过创建一个与原表结构相似的新表，并逐步将数据从旧表复制到新表，同时应用任何结构更改。在复制过程中，它会捕获并重放DML（Data Manipulation Language）操作，确保数据的连续性和一致性。复制完成后，它会原子性地替换原表。