MySQL DDL 之困如何在千万级大表下DDL?

原创

于 2025-09-22 14:13:00 发布 · 754 阅读

25 ·

CC 4.0 BY-SA版权

本文为博主原创文章，未经博主允许不得转载。

文章标签：

#mysql #DDL

引言：MySQL DDL 之困

在 MySQL 数据库管理中，对大表进行数据定义语言（DDL）操作，像是添加字段、修改字段类型、添加索引等，一直是个棘手的问题。传统的 MySQL DDL 操作在执行时，往往需要对表加锁，这就会阻塞表上的读写操作。如果是在生产环境下对大表执行 DDL，可能会导致业务系统长时间无法访问该表，造成严重的业务影响。例如，在一个电商平台中，商品信息存储在一张大表中，若在业务高峰期对该表执行添加字段的 DDL 操作，可能会使商品展示页面无法加载商品信息，购物车无法正常添加商品等，导致用户体验急剧下降，甚至可能造成订单流失。

而且，DDL 操作还可能引发主从延迟问题。在主从复制架构中，主库执行 DDL 后，从库也需要执行相同的操作。由于大表的 DDL 操作通常耗时较长，从库在执行 DDL 期间，可能会导致数据同步延迟，使得主从数据不一致。假设一个社交平台，主库上对用户消息表执行 DDL 操作，从库延迟同步，这可能导致部分用户在从库读取消息时，无法获取最新的消息，影响用户沟通和使用体验。

为了解决这些问题，业界涌现出了许多工具和技术，其中 gh-ost（GitHub's Online Schema Migration Tool）就是一款备受关注的在线架构迁移工具，它能有效解决 MySQL 大表 DDL 带来的诸多困境，接下来就让我们深入了解一下 gh-ost 的原理、使用方法及其优势。

gh-ost：工具简介与原理剖析

gh-ost 是什么

gh-ost，全称 GitHub's Online Schema Transformer，是由 GitHub 开源维护的一款专门用于 MySQL 的在线数据定义语言（DDL）工具。在 MySQL 数据库管理中，对表结构进行变更时，传统方法常常会面临诸多问题，而 gh-ost 的出现，为解决这些问题提供了新的思路和方法。

与其他一些在线 DDL 工具不同，gh-ost 最大的特点之一是它不依赖触发器来实现数据的同步。触发器在一些传统的在线 DDL 工具中被广泛使用，用于捕获源表上的增删改（DML）操作，并将这些操作应用到目标表上。然而，触发器的使用会带来一些潜在的问题，比如增加数据库的负载，因为每次 DML 操作都需要触发额外的触发器动作；可能引发与现有业务逻辑中触发器的冲突，导致不可预测的错误；而且在某些复杂的数据库架构中，触发器的管理和维护也变得更加困难。

gh-ost 则另辟蹊径，它利用 MySQL 的二进制日志（binlog）来捕获数据的变更。binlog 记录了数据库中所有的写操作，包括表结构的变更和数据的增删改。gh-ost 通过解析 binlog，能够准确地获取到源表上的所有变更操作，并将这些变更应用到一个与源表结构相同的镜像表（也称为幽灵表，ghost table）上。这种方式不仅避免了触发器带来的一系列问题，还能更高效地实现数据的同步，确保在 DDL 操作过程中，镜像表与源表的数据一致性。

工作原理详解

创建镜像表和心跳表：当使用 gh-ost 执行 DDL 操作时，它首先会在主库上创建一个与源表结构完全相同的镜像表，表名一般为原表名加上_gho后缀。例如，如果原表名为users，那么镜像表名就是users_gho。同时，gh-ost 还会创建一个心跳表，表名一般为原表名加上_ghc后缀，如users_ghc。心跳表用于记录 Online-DDL 的进度以及时间等信息，就像是一个记录 DDL 操作过程的 “小账本”，通过它可以实时了解 DDL 操作的进展情况。

执行 ALTER 操作：在镜像表创建完成后，gh-ost 会在镜像表上执行用户指定的 ALTER 操作，也就是对表结构的变更操作，比如添加字段、修改字段类型、添加索引等。这一步就像是在一个副本上进行 “改造”，不会影响到正在使用的源表。

数据同步：

- 全量数据拷贝：gh-ost 会开始将源表中的数据逐行拷贝到镜像表中。这个过程就像是把一个仓库里的货物搬运到另一个新仓库，只不过在搬运的同时，原仓库还在不断地进出货物（源表还在进行 DML 操作）。

- 增量数据同步：为了获取源表在全量数据拷贝过程中的增量变更（新的插入、更新和删除操作），gh-ost 会伪装成一个从库，连接到主库的某个从库实例上（默认连接从库，也可以通过参数指定连接主库），获取 binlog 信息。然后，它根据 binlog 中记录的变更操作，将这些增量数据应用到镜像表上，确保镜像表与源表的数据始终保持一致。例如，当源表中有一条新的用户记录插入时，gh-ost 会从 binlog 中捕获到这个插入操作，并在镜像表中执行相同的插入操作。

切换表：当全量数据拷贝和增量数据同步都完成后，gh-ost 会进入最后一个关键步骤 —— 切换表。此时，它会先在源表上加锁，防止新的 DML 操作对数据一致性产生影响。然后，确认心跳表中的时间等信息，确保数据已经完全同步。最后，将镜像表替换源表，完成整个 DDL 操作。这一步就像是把新仓库（镜像表）正式投入使用，而将旧仓库（源表）废弃。在切换表的过程中，由于只是进行表名的重命名操作，所以阻塞读写的时间非常短暂，通常只有几秒钟，大大减少了对业务的影响。

通过以上步骤，gh-ost 实现了在不影响业务正常运行的情况下，对 MySQL 表结构进行在线变更，有效地解决了传统 DDL 操作带来的锁表和主从延迟等问题。

实战演练：gh-ost 使用全流程

前期准备

在使用 gh-ost 之前，首先要确保满足一些前提条件。

MySQL 版本：gh-ost 目前需要 MySQL 版本为 5.7 及更高版本。这是因为在这些版本中，MySQL 的一些特性和功能得到了改进和完善，能够更好地与 gh-ost 配合使用，确保在线 DDL 操作的稳定性和高效性。例如，5.7 版本对 InnoDB 存储引擎进行了优化，在处理大表数据时性能有了显著提升，这对于 gh-ost 在执行数据拷贝和同步操作时非常重要。

binlog 格式：必须启用二进制日志（binlog），并且 binlog 格式需为基于行的复制（ROW-based replication，RBR）模式。这是因为 gh-ost 主要通过解析 binlog 来捕获源表的数据变更，然后将这些变更应用到镜像表上。如果 binlog 格式不是 RBR，可能会导致数据同步不准确或不完整，从而影响 DDL 操作的结果。例如，在基于语句的复制（Statement-based replication，SBR）模式下，binlog 记录的是 SQL 语句，而不是具体的数据变更，这对于 gh-ost 来说，很难准确地将数据变更应用到镜像表上。

权限要求：执行 gh-ost 操作的账户需要具备相应的权限。它需要在迁移表所在的数据库（模式）上具有 ALTER、CREATE、DELETE、DROP、INDEX、INSERT、LOCK TABLES、SELECT、TRIGGER、UPDATE 权限；或者在*.*上具有这些权限。另外，要么在*.*上具有 SUPER、REPLICATION SLAVE 权限，要么在*.*上具有 REPLICATION CLIENT、REPLICATION SLAVE 权限。这些权限是保证 gh-ost 能够顺利创建镜像表、执行 DDL 操作、读取和写入数据以及进行主从复制相关操作所必需的。例如，如果没有 ALTER 权限，就无法在镜像表上执行表结构变更操作；没有 REPLICATION SLAVE 权限，就无法从主库获取 binlog 信息进行数据同步。

满足上述条件后，就可以进行 gh-ost 的安装了。安装步骤如下：