下面通过两则案例来对MDL锁视图进行进一步的说明。

场景一：长时间未提交事务，阻塞DDL，继而阻塞所有同表的操作

客户发现表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锁，导致全备失败

客户实例最近几次全备均失败，但是业务表现似乎正常，而且最近系统业务量不高，未出现明显问题。运维团队发现全备被阻塞后，立刻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锁等待的根因，准确地进行下一步决策，有效降低对业务的影响。