mysql 5.7中mdl锁阻塞本质是长事务隐式持有mdl_read锁，导致ddl需等待mdl_exclusive锁而卡住，并连锁阻塞后续所有表操作；源头常为sleep状态但未提交的事务，需联查innodb_trx、processlist和performance_schema.metadata_locks定位。
Metadata Lock（MDL）在 MySQL 5.7 中不是“导致全表查询阻塞”，而是全表查询（尤其在 REPEATABLE READ 隔离级别下）会隐式持有 MDL_READ 锁，从而阻塞后续 DDL——反过来，DDL 卡住后，又会连锁阻塞其他查询。真正被阻塞的不是“全表查询本身”，而是所有需要访问该表元数据的操作。
为什么 SELECT 会持锁？
在 REPEATABLE READ 隔离级别下，事务中第一次执行 SELECT（无论是否全表扫描）时，MySQL 会为所查表自动加 MDL_SHARED_READ 锁，并持续到事务结束（COMMIT 或 ROLLBACK）。这不是用户显式请求的，也看不到 SHOW PROCESSLIST 中的“Locked”状态，但锁真实存在。
- 哪怕只执行
SELECT id FROM t LIMIT 1，只要在事务里，就持锁 -
mysqldump --single-transaction也会对所有 dump 表加MDL_SHARED_READ，直到 dump 完成 -
INFORMATION_SCHEMA查询（如查COLUMNS）同样触发短暂但关键的 MDL 请求
为什么阻塞会扩散？
DDL 操作（如 ALTER TABLE）必须获取 MDL_EXCLUSIVE 锁。而 MDL_SHARED_READ 和 MDL_EXCLUSIVE 互斥。一旦有长事务持着读锁不放，DDL 就卡在 Waiting for table metadata lock 状态。
- 此时新来的
SELECT、UPDATE、INSERT都要等 DDL 先拿到锁再释放——因为 DDL 在排队等排他锁，后续所有操作都得排队等 DDL 完成 - 所以你看到多个
SELECT也显示Waiting for table metadata lock，它们不是源头，是连锁受害者 - 阻塞链本质是：长事务 → DDL 卡住 → 其他所有操作排队等待 DDL
为什么 SHOW PROCESSLIST 找不到源头？
SHOW PROCESSLIST 只显示线程当前命令和状态，但 MDL 锁由服务层管理，不体现为传统锁状态。一个连接可能 Command = 'Sleep'、State = ''、Info = NULL，却仍在事务中持着 MDL_SHARED_READ 锁。
- 典型陷阱：应用用连接池执行了
BEGIN+SELECT，但没COMMIT也没关闭连接，连接被归还池中但事务未结束 - 这种连接在
PROCESSLIST里看着“空闲”，但在INNODB_TRX里trx_state = 'RUNNING'，且trx_started很早 - 必须联查：
INNODB_TRX+PROCESSLIST+metadata_locks才能定位
怎么快速确认是不是它？
直接查 sys.schema_table_lock_waits 视图，它专为这类问题设计：
SELECT * FROM sys.schema_table_lock_waits\G
-
blocking_pid是持有锁的连接 ID；waiting_pid是被卡住的 DDL 或查询 - 若返回为空，先确认：
SELECT @@performance_schema是否为 1，再启用采集器：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl'; - 注意：
blocking_pid为NULL不代表没锁，很可能是隐式事务（BEGIN后断开）在持锁
真正难处理的从来不是“查不到”，而是“查到了却不敢 kill”——比如那个持锁的连接来自核心业务中间件，kill 后触发大事务回滚，反而更卡。所以定位之后，得看 trx_isolation_level、trx_started、PROCESSLIST_HOST 综合判断是否可中断。
