一、metadata_locks 视图核心作用

performance_schema.metadata_locks 表记录 MySQL 元数据锁（MDL）的持有和等待状态，用于定位因 DDL 操作或未提交事务导致的阻塞问题‌。

二、诊断阻塞会话的步骤

‌1. 启用元数据锁监控‌
确保 metadata_locks 功能已启用：

– 检查 instruments 配置

SELECT * FROM performance_schema.setup_instruments  
WHERE NAME = 'wait/lock/metadata/sql/mdl';  

若 ENABLED 为 NO，需动态启用：

UPDATE performance\_schema.setup\_instruments  
SET ENABLED = 'YES'  
WHERE NAME = 'wait/lock/metadata/sql/mdl';  

同时确保 global_instrumentation 和 thread_instrumentation 已开启‌。

‌2. 查询元数据锁状态‌
筛选目标表（如 books）的锁信息：

SELECT  
ml.LOCK_STATUS, -- 锁状态（GRANTED/PENDING）  
ml.LOCK_TYPE, -- 锁类型（SHARED\_READ/EXCLUSIVE）  
ml.OWNER_THREAD_ID, -- 持有锁的线程 ID  
t.PROCESSLIST_ID, -- 关联的会话 ID（即 SHOW PROCESSLIST 中的 Id）  
t.PROCESSLIST_USER,  
t.PROCESSLIST_TIME  
FROM performance_schema.metadata_locks ml  
JOIN performance_schema.threads t  
ON ml.OWNER_THREAD_ID = t.THREAD_ID  
WHERE OBJECT_NAME = 'books';  

结果解析‌：

• ‌GRANTED‌：已持有锁的会话（可能是阻塞源）。
• ‌PENDING‌：等待锁的会话（被阻塞方）。
• LOCK_TYPE 为 EXCLUSIVE 表示排他锁（如 DDL 操作）‌。

‌3. 定位阻塞链‌
若存在 PENDING 状态的锁，通过 OWNER_THREAD_ID 找到持有锁的会话。例如：

+-------------+-----------------+-----------------+----------------+------------------+------------------+  
| LOCK_STATUS | LOCK_TYPE | OWNER_THREAD_ID | PROCESSLIST_ID | PROCESSLIST_USER | PROCESSLIST_TIME |  
+-------------+-----------------+-----------------+----------------+------------------+------------------+  
| GRANTED | SHARED_READ | 45 | 10 | root | 202 |  
| PENDING | EXCLUSIVE | 46 | 11 | root | 20 |  
+-------------+-----------------+-----------------+----------------+------------------+------------------+  

‌

分析‌：
会话 Id=10（对应 PROCESSLIST_ID）持有 SHARED_READ 锁。
会话 Id=11 因请求 EXCLUSIVE 锁被阻塞。
‌

4. 终止阻塞源‌
终止持有锁的会话（如 Id=10）：

KILL 10;  

完成后，被阻塞会话（Id=11）将自动恢复执行‌78。

三、典型场景案例

‌场景：未提交事务导致元数据锁阻塞‌
‌复现步骤‌：

会话 A 执行事务未提交：

BEGIN;  
SELECT * FROM books WHERE id=1; -- 隐式获取 SHARED\_READ 锁  

会话 B 执行 DDL：

ALTER TABLE books ADD COLUMN author VARCHAR(50); -- 等待 EXCLUSIVE 锁  

‌诊断‌：

metadata_locks 显示会话 A 持有 SHARED_READ 锁，会话 B 状态为 PENDING。
通过终止会话 A 或提交事务解决‌。