引言

关系型数据库，随着业务发展，经常需要加表加列来满足新的业务需求，或者增加索引以提升查询性能，这些操作都需要通过数据定义语言 (Data Definition Language, DDL) 来完成。

DDL 是结构化查询语言(Structured Query Language, SQL) 的一部分，1974 年 IBM 研究人员设计 SQL 的前身 Sequel 时有两个目标，允许用户通过 Sequel 来操纵和定义数据。当时发表的两篇论文，一篇是广为人知的 "SEQUEL: A Structured English Query Language"，介绍如何查询和修改数据，另一篇则专门介绍了 DDL^1,2，可以看出，从一开始 DDL 就是 SQL 重要的组成部分。

随后的几十年中，学术界对 DDL 要解决的核心问题“模式演化”(Schema Evolution) ，也就是“不丢失数据内容的前提下，改变数据的定义”，进行了大量研究^3,4。如今 Schema Evolution 相关研究的结果已经广泛应用在关系型、对象、文档数据库产品中，其中 Online Schema Change 能力已经成为 OLTP 数据库的标准配置，主流单机 OLTP 数据库都有自己的实现。

Online Schema Change

关系型数据库中数据以表为单位存储，读写操作依赖表的模式(Schema)和数据(Data)。DDL 通常需要同时修改模式和数据，为了避免并发问题，早期的数据库实现会在 DDL 过程中禁止目标表上的读写操作（简称锁表）。锁表保证了对模式和数据的修改是原子操作。但某些 DDL 操作涉及复制数据（比如索引构建）执行时间可能在几分钟甚至数小时。OLTP 数据库中长时间锁表会对业务产生不可预知的影响，生产环境中不可接受，因此“能够与读写操作并行执行”是 OLTP 用户对 DDL 的核心需求，也是 Online Schema Change 要解决的问题。

单机数据库

MySQL 从 5.6 版本开始提供 Online Schema Change(Online DDL)⁵ 特性，允许大多数 DDL 语句与 DML 并行执行。DDL 执行分为 Initialization, Execution, Commit Table Definition 三个阶段，通过 MDL(Metadata Lock)⁶ 保护元数据，下面以 CREATE INDEX 为例简单介绍 MySQL Online DDL 的实现。

MySQL Online DDL 的特点

分布式数据库

问题

分布式数据库通常是一个集群，出于性能考虑，每个节点需要缓存一份 Schema。如果继续采用单机数据库的 DDL 流程，则需要通过分布式锁来保证加载新版本 Schema 过程中没有读写操作进行，代价极高，并且当集群内节点不能够互相感知时将变为无法完成的任务。

讨论解决方案之前，以 CREATE INDEX 为例，看看集群节点使用不同版本 Schema 执行读写操作，带来的具体问题。

上图展示的是一个存储计算分离架构的分布式数据库，集群由 CN(计算节点) 和 DN(存储节点) 构成，每个 CN 中缓存一份 Schema。由于 CN0 和 CN1 异步加载 Schema，添加索引过程中可能存在一个时刻，CN0 认为有索引而 CN1 认为没有，此时产生两种异常：

可以看到，如果同一时刻存在两个 Schema 版本的情况无法避免，继续沿用单机数据库一步完成 Schema 版本切换的方案，会导致数据问题。那么如果“一步”切换不可行，“多步”能否解决问题？VLDB 2013 上 Google 工程师给出了一种新的 Schema Change 流程，通过增加两个中间状态来解决这个问题⁷。

解决方案 & 业界实现

Google F1 的方案引入了两个中间状态，delete_only 状态的对象上仅执行删除操作，write_only 状态的对象上支持写入，但不允许读取。依然以 CREATE INDEX 为例：

以上两个具体场景为例，说明了方案的有效性，论文⁷中对整体问题和方案做了形式化证明，网上有不少资料，团队同学之前也有过分享⁸，这里不再展开，只列举结论。

Google F1 的方案，包含两个关键点：

个关键点，将保证 Schema Change 正确性的条件，从“只能有一个版本”，降低为“多可以有两个版本”。第二个关键点，给出了 F1 系统“保证多两个版本”的实现思路。

简单来说，Google F1 的方案，成功将问题“在分布式数据库系统上实现 Online Schema Change”转化为“设计一种保证系统中多有两个 Schema 版本的协议”，并且给出了一种基于租约的协议实现。

协议内容可以概括为，以租约周期作为时间单位，协调了三个操作的节奏。

原始版本的协议十分简洁，易于描述和验证，但由于将 DDL 执行的小时长和事务执行的大时长绑定在一起，使用体验上与单机数据库有区别。对此，业界也给出了多种改进方案，比如：

从公开资料可以看出，使用存储分离架构的产品对 F1 方案的改进主要集中在缩短 DDL 执行周期，DDL 执行导致部分长事务被回滚的问题并没有解决。PolarDB-X 在使用体验上高度兼容 MySQL，需要设计自己的改进协议。

改进方案

回顾一下要解决的问题，“保证系统中多有两个 Schema 版本”，隐含的意思是 Schema 在系统中存在多个拷贝，且每个拷贝的版本可能不同。协议要做的，就是协调每个拷贝的更新操作，给出旧版本从系统中消失的可靠时间点。

分布式数据库中有两个地方会缓存 Schema：

节点上缓存的 Schema，通常由每个节点上的后台线程定时刷新，刷新间隔为一个租约周期。如果节点刷新 Schema 失败，则回滚所有未完成的事务，停止提供服务，直到获取到新版本的 Schema。这样 Schema 从 V0  变更为 V1 后，只需要等待一个租约周期，就可以保证所有节点要么已经在使用 V1 版本，要么回滚了所有使用 V0 的事务，并停止提供服务。

事务中缓存的 Schema 版本无法更新，因此协议需要协调事务和 DDL 执行的顺序，确保使用 V0 版本的事务全部 commit/rollback 之后才继续执行 V1 到 V2 的版本变更。也就是说，对于执行过程中有 Schema 版本变更发生的事务，有两种直观的处理：

Google F1 的实现中，通过限制每个事务的大执行时长为一个租约周期，简化判断事务结束时间的逻辑。引入租约周期的限制后，按照起止时间的不同，可以将事务分为下面几类：

可以看到，F1 会保证执行时间在一个租约周期内的事务 T₄ 不受影响，但也影响了无 DDL 执行时的事务 T₁, T_3，同时会导致 DDL 执行时长也至少为一个租约周期。CockroachDB 在此基础上增加了事务结束释放租约的机制，将切换为 V₂ 版本的时间限制为后一个 V₀ 版本租约的过期时间，仅当有 V₂ 版本写入时才判断租约是否失效。这样缩短了 DDL 的执行时间，并且仅在有 DDL 执行时限制事务的大执行时长。

仔细分析可以发现，租约其实有两用途，确定使用旧版本的事务结束 和 保证异常节点上使用旧版本的事务无法提交。PolarDB-X 在节点内部增加 MDL，通过短暂获取旧版本 Schema 上的 exclusive MDL，排空使用旧版本的事务，将切换为 V₂ 版本的时间限制为 T₅, T₆ 结束之后。同时，如果 GMS 组件确认节点异，标记旧版本 Schema 失效，等待一个租约周期后可以保证异常节点上使用旧版本的事务无法提交。

从用户角度出发，理想 Online Schema Change 方案应该满足下面三个特点，没有 DDL 流程执行时不对事务增加过多额外开销；DDL 流程中，事务不会被强制回滚；DDL 的执行时间尽可能短。MySQL Online DDL 基本符合上述特点，而存储分离架构的产品都有一些取舍，以下从这三个角度出发，对比现有方案和 PolarDB-X 的实现：

可以看到，PolarDB-X 方案有如下特点：

PolarDB-X Online Schema Change 实现

PolarDB-X 是一个分布式 HTAP 数据库，采用存储分离架构，高度兼容 MySQL 生态，支持 Online Schema Change。

DDL 执行流程

收到用户的 DDL 语句后，首先由接受语句的 CN 节点进行校验，并生成 DDL Job 提交到 Global Meta Service (GMS) 的任务队列中，随后 GMS 通知 CN 节点中的 DDL Worker 领取任务，开始推进 DDL 流程和 Schema 版本变更。

上图展示 CREATE GLOBAL INDEX 的执行过程。DDL Worker 发起 Schema 版本变更时，首先通过 GMS 的 Sync 机制尝试通知其他几点加载新版本并排空使用旧版本的事务。如果 GMS 判定有节点异常，则等待一个租约周期后设置旧版本 Schema 为失效状态，继续推进 Schema 版本变更。事务提交时判断节点是否正常刷新了 Schema Cache，以及自己使用的 Schema 是否依然有效，如果不满足则事务回滚。

Schema 版本变更流程

收到更新元数据版本的通知后，首先检查当前是否已经加载了该版本的 Schema，若尚未加载，加载新版本 Schema，之后尝试获取旧版本上的 MDL，若获取 MDL 成功，代表节点上使用旧版本 Schema 的事务已经结束，该节点上的 Schema 版本变更完成，返回成功。若获取 MDL 失败（超时），返回错误，交给上层重试。

同时，事务的条查询执行前，获取新 Schema 版本上的 MDL，目前只有S锁和X锁，通过队列保证公平性，但不需要死锁检测等 MySQL MDL 的组件。MDL 为内存中的锁，不落盘，节点重启时清空。

总结

Online Schema Change 是 HTAP 数据库的必选功能。单机数据库中，Schema 只有一个版本，通过加锁来避免 DDL 和 DML 并发导致数据问题，通过缩小加锁的范围来实现 Online Schema Change。分布式数据库通过引入中间状态，允许同时存在至多两个 Schema 版本，避免加锁，支持 Online Schema Change 的关键点转化为，设计一种节点交互协议，保证系统中至多同时存在两个 Schema 版本。PolarDB-X 实现的协议，结合 MDL 和租约，不对事务执行引入额外开销；无异常节点的情况下，Schema 版本变更不影响事务执行，无数据回填的 DDL 操作毫秒级完成；存在异常节点时，仅阻止异常节点上的事务提交，无数据回填的 DDL 操作分钟级完成，与业界方案保持一致。