【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

）操作，确保数据的连续性和一致性。复制完成后，它会原子性地替换原表。
包含以下几个步骤：

• 创建副本：同样创建一个与原表结构相同的新表，但在此基础上进行所需的结构更改。
• 数据复制：开始将原表的数据复制到新表，同时使用多线程技术来加速复制过程。
• DML捕获与重放：使用二进制日志或其他机制捕获原表的所有DML操作，并在新表上重放，以保持数据同步。
• 表替换：数据复制和DML重放完成后，执行原子性的表替换操作。
• 后期处理：清理临时资源，如删除旧表或调整索引。

优点：

• 高度自动化：提供了丰富的选项和自动化功能，简化了在线模式更改的过程。- 它可以自动从源表复制数据到新表。这个过程是增量的，意味着它会持续监控源表上的更改（包括插入、更新和删除），并将这些更改同步到新表，直到模式更改完成。- 提供了详细的进度报告，包括复制了多少数据、剩余多少数据、复制速率等信息，这有助于DBA实时监控操作状态- 允许用户调整各种参数，如内存使用、并发级别、复制策略等，以便更好地适应不同的硬件条件和数据库负载。这些高级配置选项可能在标准的在线DDL操作中是不可用的- 内置了错误恢复机制，能够在遇到问题时自动尝试恢复，或者至少保持数据的一致性，避免半途而废导致的问题。这在标准的在线DDL操作中可能需要额外的手动步骤来实现。
• 灵活：支持多种数据复制策略，如多线程复制，以提高效率，也就是说可以并行处理多个分区或表的一部分，从而加速数据迁移过程，减少对数据库性能的影响，并且允许用户根据数据库的具体情况定制执行计划，比如先复制哪些数据、后复制哪些数据，这在标准的在线DDL操作中可能不是一个可选功能
• 兼容性：适用于多种MySQL版本和配置环境。

缺点：

• 需要将老表的所有数据都拷贝到新表上，这就意味着拷贝期间，磁盘IO可能较高。 要拷贝全量数据，所以执行时间也会很长。
• 新临时表存放数据也需要空间（最大空间需求可能和原表一样），拷贝数据时还会产生大量binlog，所以对于本来空间就紧张的实例而言，这方式真的是雪上加霜

3.各种常用DDL操作如何选择

原理理解之后，到选择阶段就很容易了，以下是我整理的常用的选择，如果想了解更多，可以看这篇文章：
https://developer.jdcloud.com/article/3923?mid=30