alter table 卡在 Waiting for table metadata lock 谁没提交

SELECT OBJECT_NAME, LOCK_TYPE, LOCK_STATUS, OWNER_THREAD_ID
FROM performance_schema.metadata_locks
WHERE OBJECT_NAME = 'orders' AND LOCK_STATUS = 'GRANTED';

给订单表加字段，alter 语句停在 Waiting for table metadata lock 上 6 分钟，后面所有 select 也一起堵住，processlist 里三十多条同样的等待。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。

追下去是这么回事：DDL 需要排他的元数据锁，前面只要有事务碰过这张表还没结束，就得排队。排队期间新来的查询又排在 DDL 后面，整张表被堵死。持锁的常常是一条 sleep 状态但事务没结束的连接。

「MDL 元数据锁等待」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。监控和日志的时间要对上，时区不一致会多绕很大一圈。

临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。

处理上按这个顺序：先查 metadata_locks 找到 GRANTED 的那条 看 OWNER_THREAD_ID；用线程 id 反查 processlist 确认是不是空闲事务；kill 掉持锁连接 再重试 alter；把 DDL 放到低峰 并给 lock_wait_timeout 设上限。

确认没问题再收工，metadata_locks 里只剩一条 PENDING 很快转成 GRANTED alter 在几十秒内完成 后面的 select 不再堆着。