MDL锁（Metadata Lock），即元数据锁。元数据指的是描述数据的数据，对数据及信息资源的描述性信息，在数据库中元数据即数据字典信息，包括db，table，function，procedure，trigger，event等。
MySQL从 5.5版本开始引入MDL锁，MDL锁主要为了保证元数据的一致性（主要是保证DDL操作与DML操作之间的一致性），用于处理不同线程操作同一元数据对象的同步与互斥问题，在各个业务场景中会十分频繁地使用到。
具体而言，MySQL引入MDL锁可以解决如下问题：一是事务隔离问题，比如在可重复读隔离级别下，会话A在2次查询期间，会话B对表结构做了修改，2次查询结果就会不一致，无法满足可重复读的要求。二是数据复制问题，比如会话A执行了多条更新语句期间，另外一个会话B做了表结构变更并且先提交，就会导致slave在重做时，先重做alter，再重做update时就会出现复制错误的现象。
何为MDL锁视图？
社区版MySQL无法获取表MDL锁的详细信息，当客户遇到类似“Waiting for metadata lock”的问题而阻塞DML或DDL后，由于无法确定各session之间的关联，往往无从下手，复杂情况下，只能重启实例，从而增加解决问题的成本，对业务产生较大影响。而且在业务场景较复杂的情况下，一旦涉及对数据库元数据的互斥操作（如DDL、LOCK Table等），此类问题便会频繁发生，给一线运维和客户带来很大的困扰。
针对以上痛点，华为云数据库MySQL在充分调研内核的基础上，推出了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锁，该值为空
MDL锁视图好在哪？
下面通过两则案例来对MDL锁视图进行进一步的说明。
场景一：长时间未提交事务，阻塞DDL，继而阻塞所有同表的操作
|
T |
Session 2 |
Session 3 |
Session 4 |
Session 5 |
|
T1 |
begin; select *from t1; |
|
||
|
T2 |
begin; select *from t2; |
|
||
|
T3 |
truncate table t2; (blocked) |
|
||
|
T4 |
|
|
|
begin; select *from t2; (blocked) |
客户发现表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，便可以让业务继续运行。
场景二：长时间持有MDL锁，导致全备失败
|
T |
Session 2 |
Session 3 |
Session 4 |
Session 5 |
|
T1 |
lock tables t1 write; |
|
||
|
T2 |
select *from t1; |
insert into t2; |
select *from t3 |
|
|
T3 |
Lock tables for backup; (blocked) |
|
||
|
T4 |
|
begin; select *from t2; |
|
begin; insert into t3; |
客户实例最近几次全备均失败，但是业务表现似乎正常，而且最近系统业务量不高，未出现明显问题。运维团队发现全备被阻塞后，立刻show processlist，发现有多个活跃的用户session：
全备是基于xtrabackup，在执行真正的备份之前需要执行lock tables for backup，但从show processlist中只能看到：lock tables for backup时一直被某个MDL锁阻塞，全备超时失败；客户的多个session业务量很小，都处于sleep状态，于是客户继续执行show open tables where in_use >=1：
发现有个表t1始终处于in use状态，所以猜测是用户某个session持有了该表t1的MDL锁未释放，导致lock tables for backup等待超时。但是结合show processlist仍然无法确定是哪个session持有表t1的MDL锁，想让全备执行成功，只能通知客户逐一断连session或者重启实例。
引入MDL锁视图后，客户执行SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO:
结合show processlist的结果，从元数据锁视图中可以明显看出，session 4 pending在全局backup lock上；session 2持有全局的backup lock，该MDL锁类型为MDL_EXPLICIT，global级别。因此，客户只需要在session 2显式调用unlock tables释放锁或者kill session 2即可让业务继续运行。
通过以上两个案例，MDL锁视图的重要性不言而喻，它可以让客户和一线运维人员清晰地查看数据库各session持有和等待的元数据锁信息，从而找出数据库MDL锁等待的根因，准确地进行下一步决策，有效降低对业务的影响。
