如何分析MySQL慢日志中因为MDL元数据锁导致的查询卡顿问题？-mysql教程-PHP中文网

mdl锁阻塞导致慢日志中简单sql执行时间异常偏长，核心判断依据是query_time远大于lock_time且rows_examined极小；需通过show processlist和sys.schema_table_lock_waits定位持锁者，重点排查未提交事务、长时间运行的ddl及显式表锁。

如何分析mysql慢日志中因为mdl元数据锁导致的查询卡顿问题？

慢日志里“执行时间”超长但SQL本身很简单，大概率是MDL锁卡住

MySQL慢日志记录的是语句从进入执行器到返回结果的总耗时，Waiting for table metadata lock状态不会被跳过——它会被计入Query_time。所以你看到SELECT * FROM orders WHERE id = 123耗时120秒，实际可能99%时间都在等MDL锁，而不是查数据。

关键判断依据：Query_time远大于Lock_time（比如Query_time: 120.345，Lock_time: 0.000123），且Rows_examined极小（如1或0），基本可锁定为MDL阻塞。

别信Rows_examined值：它只统计真正扫描的行数，等锁期间不计入
注意Rows_sent是否为0：如果是，说明查询甚至没走到返回阶段，大概率卡在锁等待入口
检查SQL_text是否带事务控制关键词：如开头有BEGIN、START TRANSACTION，或结尾缺COMMIT/ROLLBACK

用show processlist快速定位谁在等锁、谁在持锁

登录MySQL后直接执行：SHOW FULL PROCESSLIST;，重点扫三列：

State列：找大量线程停在Waiting for table metadata lock，且Time > 30s
Info列：看被卡住的SQL是否集中在同一张表（如全是SELECT * FROM user）
Id列：记下其中一个waiting_pid（比如Id=1024）

再查谁在持锁：SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = 1024; —— 这不是查等待者本身，而是通过等待者的ID反推其关联线程信息；真正持锁者通常要结合sys.schema_table_lock_waits或performance_schema.metadata_locks确认。

更直接的方式（MySQL 8.0+）：SELECT * FROM sys.schema_table_lock_waits\G，它会直接给出blocking_pid和waiting_pid，以及锁涉及的表名和操作类型。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

持锁源头往往是这三类操作，别只盯着慢SQL

MDL锁不是由慢查询本身引起的，而是由某些“看似无害”的操作长期持有S锁导致的。重点排查以下三类：

BEGIN后没COMMIT：应用层开了事务，中间调了HTTP接口、sleep、或异常退出，导致SELECT一直持有S锁
未提交的ALTER TABLE：比如ALTER TABLE orders ADD COLUMN status TINYINT在大表上执行，会持X锁，后续所有DML/SELECT都排队
FLUSH TABLES WITH READ LOCK或LOCK TABLES：这类显式锁命令一旦没释放，整库读写都会卡死

特别注意：blocking_query字段为空时，说明持锁者SQL已执行完，但事务仍开着——此时Info列显示NULL，Command是Sleep，Time持续增长，就是典型未提交事务。