摘要：数据库中的元数据锁（MDL ，Metadata Lock），用来保护表元数据信息的一致性。用户对表进行读写操作或结构变更时，系统会添加不同类型的MDL锁。当客户业务设计不合理，有部分事务长时间持有MDL锁时，可能会阻塞其他会话获取相应的MDL锁。此时，用户使用
摘要：TaurusDB推出MDL锁视图功能，帮助用户迅速识别并处理MDL锁阻塞问题，从而有效减少对业务的负面影响，提升数据库管理效率。
本文分享自华为云社区《【华为云MySQL技术专栏】TaurusDB MDL锁视图-云社区-华为云》，作者：GaussDB 数据库。
数据库中的元数据锁（MDL ，Metadata Lock），用来保护表元数据信息的一致性。用户对表进行读写操作或结构变更时，系统会添加不同类型的MDL锁。当客户业务设计不合理，有部分事务长时间持有MDL锁时，可能会阻塞其他会话获取相应的MDL锁。此时，用户使用执行‘SHOW PROCESSLIST’命令，通常会看到多个会话处于 “Waiting for metadata lock” 状态。但由于无法明确各个会话ID之间的关联，往往无法快速找到导致大量MDL锁等待的根源，使得用户不得不盲目地Kill大量可疑的会话，甚至直接重启实例来快速恢复业务，这种做法无疑增加了解决问题的成本，对业务产生较大影响。
因此，自社区MySQL 5.7版本之后，在PERFORMANCE_SCHEMA 库中新增了METADATA_LOCKS 表，用于记录系统中MDL锁的状态信息，但是需要客户启用 Performance Schema 性能分析监控插件。启用后，Performance Schema 会收集大量的性能数据，包括SQL语句执行情况和实例内的锁状态信息等，这会对 MySQL 实例的性能产生一定的负担，尤其在高并发的生产环境中，性能开销更为明显。
鉴于此，TaurusDB推出MDL锁视图功能，帮助用户迅速识别并处理MDL锁阻塞问题，从而有效减少对业务的负面影响，提升数据库管理效率。
表1 MDL锁阻塞案例
由于SESSION 3存在一个长事务未提交，会一直持有t2表的MDL_SHARED_READ（SR）类型锁。当SESSION 4对表t2执行TRUNCATE操作时，需要获取MDL-EXCLUSIVE（X）锁，但由于MDL锁类型和SR锁不兼容而被阻塞。
随后，SESSION 5的DML操作在添加SR类型的锁时，发现MDL锁等待队列中有比SR类型的锁优先级更高的X锁在等待，所以SESSION 5的SR锁请求也会处于等待状态，详细原因可参考《【华为云MySQL技术专栏】TaurusDB新特性解读：非阻塞DDL》。
用户发现DDL和DML操作都被阻塞后，执行SHOW PROCESSLIST查看原因。在SHOW PROCESSLIST的信息中，只能看到如图1中的结果：
图 1 SHOW PROCESSLIST结果
SESSION 4执行TRUNCATE操作时，被其他SESSION持有的table metadata lock阻塞；SESSION 5执行SELECT操作时，也同样被阻塞；无法确定哪个会话（2或3？）阻塞了SESSION 4和SESSION 5；此时，如果业务盲目地去kill其他会话（2或3），可能会影响其他不相关的业务，从而加大问题处理的成本。在实际的生产业务中，可能有更多的会话，用户从成百上千的会话信息中几乎无法找到导致MDL锁等待的根源，只能盲目地Kill大量的会话或者重启实例来快速恢复。而且用户在事后也无法定位到根因，从源头杜绝此类问题的再次发生。刚好，TaurusDB的MDL锁视图功能在这个时候就可以发挥作用。
TaurusDB的MDL锁视图以系统表的形式呈现，该表位于INFORMATION_SCHEMA库下，表名为METADATA_LOCK_INFO。其中每一行的信息表示一个会话持有或正在等待的MDL锁信息。
每个字段的具体含义，如表2所示：
表2 MDL锁视图表字段含义
此表的查询结果中，同一个会话可能持有多行MDL锁的相关信息。主要有以下几方面的原因：
1）当执行涉及多张表的连表查询时，会给每一个表添加MDL_SHARED_READ模式的MDL锁。
2）事务级别的MDL锁，只有在事务结束时才会释放。因此，当一个事务涉及多张表的DML操作时，这个会话会同时持有多个MDL锁，直到事务结束。
3）在DDL语句的执行过程中，需要添加多种类型的MDL锁。例如，在添加列的DDL语句中，可能会添加Backup lock,Global read lock,Schema metadata lock,Table metadata lock，并且在不同阶段对锁的模式进行升/降级。
针对表格1中的MDL锁阻塞场景，用户可以执行以下SQL语句：SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO;
再结合SHOW PROCESSLIST的输出结果，快速定位到问题根因。
在图2元数据锁视图的结果信息中，我们应该从PENDING状态的会话开始入手。
图 2 元数据锁视图结果
根据MDL锁等待的TABLE_SCHEMA和TABLE_NAME信息，找到其他Thread ID下，具有相同库名和表名且状态是GRANTED的MDL锁信息。这个THREAD ID即是造成锁等待的会话。
基于以上原理，我们可以看出:
会话4在等待获取test库t2表的MDL_EXCLUSIVE模式的元数据锁；会话5在等待获取test库t2表的MDL_SHARED_READ模式的元数据锁；会话3持有test库t2表t2的MDL锁，该MDL锁为事务级别，只要session 3 的事务不提交，session 4和5便会一直阻塞。所以，通过MDL锁视图，我们只需要在会话3中执行Rollback或者Commit，便可以让业务继续运行。虽然MDL锁视图可以帮助定位到导致大量MDL锁等待的根源，但是当会话较多时，表中很多不相关的MDL锁信息查看起来也会耗费大量时间，这里我们提供一个可以快速查找到阻塞会话的SQL。在发生问题时，只要执行一下这个语句，就可以迅速找到需要kill的会话。
SELECT f.processlist_id, p.Info AS sql_infoFROM (SELECT DISTINCT c.blocking_processlist_id AS processlist_idFROM (SELECT DISTINCT b.THREAD_ID AS blocking_processlist_idFROM information_schema.metadata_lock_info aJOIN information_schema.metadata_lock_info bON a.TABLE_SCHEMA = b.TABLE_SCHEMAAND a.TABLE_NAME = b.TABLE_NAMEAND a.lock_status = 'PENDING'AND b.lock_status = 'GRANTED'AND a.THREAD_ID b.THREAD_ID) cWHERE c.blocking_processlist_id NOT IN (SELECT DISTINCT d.THREAD_ID AS blocked_processlist_idFROM information_schema.metadata_lock_info dJOIN information_schema.metadata_lock_info eON d.TABLE_SCHEMA = e.TABLE_SCHEMAAND d.TABLE_NAME = e.TABLE_NAMEAND d.lock_status = 'PENDING'AND e.lock_status = 'GRANTED'AND d.THREAD_ID e.THREAD_ID)) fJOIN information_schema.processlist p ON processlist_id = p.Id;基于对《【华为云MySQL技术专栏】TaurusDB MDL实现机制解析》中MDL锁相关数据结构和MDL锁添加、释放流程的分析，TaurusDB在INFORMATION_SCHEMA库下添加了MDL锁视图。
在TaurusDB的内部架构中，每一个用户连接有一个THD（Thread Handler，线程处理器）对象，这些THD对象统一由Global_THD_manager结构体进行管理。如图3所示，每个THD对象关联了一个MDL_context实例，这个实例提供了线程级的MDL锁操作接口，包括申请、释放MDL锁以及锁的升降级。
图 3. MDL锁基本概念图
其中，THD中的MDL_context也有两个变量m_ticket_store和m_waiting_for用于维护会话持有和等待的MDL锁的信息。
m_ticket_store: 用来存储当前线程获取的所有MDL_ticket。为了提升搜索效率，根据MDL锁的持续时间（语句执行时间段，事务执行时间段和显示指定时间段）将其划分为三个链表，在需要获取MDL锁前，会先在这些链表内查询是否已经获取到了相同的或这是更强类型的MDL锁，如果搜索不到继续获取MDL锁。2. m_waiting_for：用来存储当前线程正在等待的MDL锁，一个线程同一时刻只能等待一种类型的MDL锁。
每一个链表中的MDL_ticket对象是每个线程已经获取到的MDL锁或者是要请求的MDL锁的详细信息，其结构体内包含MDL锁的模式（enum_mdl_type）、MDL锁的持续时间（enum_mdl_duration）和MDL锁对象（MDL_lock）。其中，MDL_lock由MDL_key唯一标识。MDL_key是一个三元组，由命名空间（enum_mdl_namespace）、库名和对象名组成。
因此，在用户查询MDL锁视图时，实现流程如图4所示，只需要遍历所有会话THD的MDL_context对象，根据其m_ticket_store链表中的每一个MDL_ticket对象构造出处于GRANTED状态的MDL锁信息。同理，通过m_waiting_for对象获取到处于PENDING状态的MDL锁信息。最后，将结果集返回给客户端展示即可。
图 4 MDL锁视图实现流程
其中，i_s_metadata_lock_info_fill_table和List_THD_MDL_tickets为核心函数，用来实现遍历Global_THD_manager中的THD并从其MDL_context中构造当前会话的持有和等待的MDL锁信息。
i_s_metadata_lock_info_fill_table {//对系统中每一个THD执行List_THD_MDL_tickets函数找到持有和等待的MDL锁Global_THD_manager::get_instance->do_for_all_thd_copy(List_THD_MDL_tickets)}List_THD_MDL_tickets {// 获取当前THD的MDL_context：MDL_context &mdl_ctx = inspect_thd->mdl_context;// 获取当前THD持有的MDL锁 const MDL_ticket_store &m_ticket_store = mdl_ctx.get_mdl_ticket_store;// 遍历每个m_ticket_store的三个作用范围内的MDL_ticket for (int i = 0; i (mdl_ctx.get_m_waiting_for);if (ticket != nullptr) {// 填充MDL锁的额外信息，PENDING状态和作用范围 lock_extras.lock_status = MDL_ticket::PENDING;lock_extras.duration = ticket->get_duration;// 根据MDL_ticket中的信息填充到MDL锁视图中fill_row_callback(ticket, &lock_extras, args);}}TaurusDB的MDL锁视图INFORMATION_SCHEMA.METADATA_LOCK_INFO，可以在不开启Performance Schema性能监控插件时，获取到实例系统中所有MDL锁的持有和等待状态。熟练的使用MDL锁视图，可以帮助用户快速地定位和分析导致大量 MDL 锁等待的根本原因，还能够根据分析结果进行迅速有效的处理，解决MDL长时间锁等待问题，并且不会因为依赖Performance Schema性能监控插件而对系统性能产生任何影响。
来源：小顾看科技
