PolarDB-X 让“Online DDL”更Online

数据库的用户对数据库都有一个很简单的要求：

“我能不能随时随地做DDL，不要让我守到半夜再搞了。”

为了这个目标，各种各样的数据库采用了不同的方法来优化DDL这件事，MySQL也从5.6开始逐渐支持“Online DDL”。

但问题是，为何已经到了MySQL 8.0的时代，你能看到的各种MySQL佳实践\开发规范里，依然建议把DDL放在业务低峰期来做呢。PolarDB-X对此作了很多优化，期望让用户做DDL的时候能更任性。

我们得先看一下，MySQL的DDL，为什么不那么“Online”。

MySQL中的MDL（元数据锁）

MySQL中有个MDL，它会保证在DDL变更过程中，所有的事务都在使用同一份元数据。

例如，我们对一个表做一个加列的操作，ALTER TABLE t1 ADD COLUMN(c1 int)，MDL确保正在运行的事务，要么全部能看到c1列，要么全部看不到c1列。实际上，MDL起到了元数据切换过程中，排空已有事务的效果。在MySQL中，DDL/DML/DQL等操作，都会对元数据加锁。

MDL会带来一些问题，我们看下面的例子：

时间点0：我们在连接1中，对t1表做一个INSERT操作，但是不要提交这个事务

时间点1：我们在连接2中，对t1表做一个添加索引的DDL操作，这个DDL操作会阻塞住

时间点2：我们在连接3中，对t1表做一个SELECT操作，会发现，这个只读操作也会阻塞住

时间点3：提交连接1的事务

连接2的DDL操作立即返回结果

连接3的SELECT操作立即返回结果

这个就很奇怪了，一般我们都以为：

只读操作不会被写操作阻塞，为什么SELECT语句都会阻塞？
MySQL的创建索引操作（特指例子里这个很常见的DDL）不是ONLINE的吗，为什么会阻塞我的业务？

以上现象的原因就在于MDL锁上：

连接1的INSERT对t1的元数据加了读锁；
连接2的DDL获取t1的排它锁，连接2会被连接1阻塞，同时锁住后续的所有读请求；
连接3的SELECT获取t1的读锁，被连接2阻塞住。

从上面的现象看，MDL锁带来了如下的问题：

如果DDL执行之前有长事务，那会阻塞后续这个表上的所有请求（无论读写），进一步占用MySQL的线程资源，甚至引发雪崩，导致其他表的访问也出现问题；
MySQL虽然有ONLINE DDL，这个ONLINE更多体现在回填数据阶段。DDL依旧只能在业务低峰期来使用，没有达到真正ONLINE（完全不阻塞业务请求）的目的。

这个事是很坑的，我们需要的是真正的ONLINE DDL能力。

元数据的版本

这里要先解释一个概念，什么是一个元数据的版本？

有一个误区是，一个DDL操作（比如上述的加索引的操作），并不是只有“有索引”“没索引”两个版本，而是分成了多个版本。

例如PolarDB-X中的CREATE INDEX操作，整个过程会涉及ABSENT(vn)，DELETE_ONLY(vn+1)，WRITE_ONLY(vn+2)，PUBLISH(vn+3)多次版本切换。

对于MySQL来说，也有类似的概念，即在MySQL中，一次DDL操作可能会需要多次获取MDL的操作，这也加剧了MySQL DDL过程中MDL的争抢。

双版本元数据

为了解决MDL的问题，让DDL能够做到真正的ONLINE，PolarDB-X使用双版本元数据来解决这个问题。

所谓多版本元数据指的是，PolarDB-X集群中，允许多同时存在两个版本的元数据（vn与vn+1），每个事务使用的元数据版本由其事务开始时候的元数据版本为准。当使用低版本元数据的事务全部结束之后，低版本的元数据会被清理掉。