TaurusDB DDL必知必会 

相比其他数据库，TaurusDB在DDL的效率和易用性有显著提升，下面让我们来一一了解：

元数据锁（MDL）视图支持 

社区版MySQL无法获取表MDL锁的详细信息，当我们遇到类似“Waiting for metadata lock”的问题而阻塞 DML或DDL后，由于无法确定各session之间的关联，往往无从下手，复杂情况下，只能重启实例，从而 增加解决问题的成本，对业务产生较大影响。

而且在业务场景较复杂的情况下，一旦涉及对数据库元数据的互斥操作（如DDL、LOCK Table等），此类问题便会频繁发生，给数据库使用、运维带来很大的困扰。

针对以上痛点，华为云数据库TaurusDB在充分调研内核的基础上，推出了MDL锁视图特性。通过此特 性，可以清晰查看数据库各session持有、等待的元数据锁信息，方便现网运维进行问题定位，有效进行 系统诊断，帮助我们更好地优化自身业务。

MDL锁视图以系统表的形式呈现，该表位于INFORMATION_SCHEMA，表名：METADATA_LOCK_INFO，表 结构如下：

MDL锁视图主要由7个字段组成，各字段详情为：

• THREAD_ID：session的ID，即会话ID 

• LOCK_STATUS：MDL锁的状态，主要分为PENDING和GRANTED两种，分别表示session正在等待该 MDL锁和session已获得该MDL锁 

• LOCK_MODE：加锁的模式，如MDL_SHARED 、MDL_EXCLUSIVE 、MDL_SHARED_READ、 MDL_SHARED_WRITE等 

• LOCK_TYPE：MDL锁的类型，如Table metadata lock、Schema metadata lock、Global read lock、 Tablespace lock等 

• LOCK_DURATION：MDL锁的范围，有三种取值：MDL_STATEMENT、MDL_TRANSACTION、 MDL_EXPLICIT，分别表示语句级别、事务级别、global级别

• TABLE_SCHEMA：数据库名，对于部分global级别的MDL锁，该值为空 

• TABLE_NAME：表名，对于部分global级别的MDL锁，该值为空

下面我们来看一个实例：

我们发现表t2的truncate一直被阻塞后，业务流程中对表t2的select操作也全部被阻塞。DDL被阻塞后， 立刻执行show processlist：

但是通过processlist信息，只能看到session 4执行truncate操作时被其他session持有的table metadata lock 阻塞，session 5执行select操作时也同样被阻塞，无法确定哪个session阻塞了session 4和session 5。

此时，如果盲目的去kill其他session（2或3）会给线上业务带来很大风险，因此只能等待其他session释 放该MDL锁。

而当我们引入MDL锁视图后，执行SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO:

结合show processlist的结果，从元数据锁视图中可以明显看出，session 4 pending在表t2的metadata lock，session 3持有表t2的metadata lock，该MDL锁为事务级别，只要session 3的事务不提交，session 4 便会一直阻塞。因此，我们只需要在session 3中执行commit或kill session 3，便可以让业务继续运行。

原子（Atomic）DDL 

在多数传统数据库中，DDL操作是非原子型的操作，如果在执行过程中遇到机器掉电或故障重启，会出 现部分表文件残留的情况，这样会导致DDL没有完成也没有回滚，出现数据库服务无法启动的问题。

一个例子：在DDL操作期间出现机房掉电导致服务器重启，很容易出现元数据不一致问题，导致数据 库服务无法启动。此时需要对数据进行恢复，通常需要花费半小时甚至数小时的时间。而， TaurusDB可以保证DDL操作原子化，则无需担心出现此类问题。

TaurusDB支持DDL操作原子化，即，相应操作要么全部成功，要么全部被回滚。举例而言：

1. DROP TABLES – 所有表被DROP，或没有任何表被DROP 

2. DROP SCHEMA – 所有DB及DB下的元素被DROP，或没有任何DB及元素被DROP 

3. DROP VIEW – 所有视图被DROP，或没有任何视图被DROP 

4. CREATE USER – 所有用户创建成功，或没有任何用户被创建 

5. DROP USER – 所有用户DROP成功，或没有任何用户被DROP 

6. GRANT – 所有用户/角色授权成功，或者没有任何用户/角色被授权
   

立即（Instant）DDL 

TaurusDB可实现ADD COLUMN等操作立即完成，节省DDL变更耗时，并减少对并发的DML操作的影响。

可支持Instant DDL的具体操作罗列如下：

Change index option Rename table (in ALTER way) SET/DROP DEFAULT MODIFY COLUMN Add/drop virtual columns Add columns(non-generated) – We call this instant ADD COLUMN

示例如下：

mysql> CREATE TABLE t1 (a INT, b INT, KEY(b)); Query OK, 0 rows affected (0.70 sec)
 
mysql> # Modify the index can be instant if it's a trivial change mysql> ALTER TABLE t1 DROP KEY b, ADD KEY b(b) USING BTREE, ALGORITHM = INSTANT; Query OK, 0 rows affected (0.14 sec) Records: 0  Duplicates: 0  Warnings: 0
 
mysql> # Rename the table through ALTER TABLE can be instant mysql> ALTER TABLE t1 RENAME TO t2, ALGORITHM = INSTANT; Query OK, 0 rows affected (0.26 sec)
 
mysql> # SET DEFAULT to a column can be instant mysql> ALTER TABLE t2 ALTER COLUMN b SET DEFAULT 100, ALGORITHM = INSTANT; Query OK, 0 rows affected (0.09 sec) Records: 0  Duplicates: 0  Warnings: 0
 
mysql> # DROP DEFAULT to a column can be instant mysql> ALTER TABLE t2 ALTER COLUMN b DROP DEFAULT, ALGORITHM = INSTANT; Query OK, 0 rows affected (0.08 sec) Records: 0  Duplicates: 0  Warnings: 0
 
mysql> # MODIFY COLUMN can be instant mysql> ALTER TABLE t2 ADD COLUMN c ENUM('a', 'b', 'c'), ALGORITHM = INSTANT; Query OK, 0 rows affected (0.35 sec) Records: 0  Duplicates: 0  Warnings: 0

不同DDL算法的效率对比

以ADD COLUMN为例，对于一张1,000,000行记录的表进行ADD COLUMN操作，分别采用INSTANT/INPLACE 和COPY算法，其耗时对比如下：

可见，INSTANT DDL的效率优势是非常明显的。