alter table卡在waiting for table metadata lock，是因为ddl需获取mdl写锁，而此前未提交的select/insert等操作已持有mdl读锁，二者互斥；即使启用algorithm=inplace或lock=none，元数据变更阶段仍需短暂x锁，故仍会阻塞。
为什么ALTER TABLE卡在Waiting for table metadata lock
因为MDL（元数据锁）不是“可选配件”，而是MySQL强制施加的保护机制——只要访问表，就自动加锁；只要事务没结束，S锁就一直挂着。DDL需要X锁，而X锁与任何未释放的S锁互斥。所以不是DDL“太慢”，是它被前面一个没提交的SELECT或INSERT死死拦住了。
常见错误现象：
- 执行
ALTER TABLE后，SHOW PROCESSLIST里状态长期卡在Waiting for table metadata lock - 后续所有对该表的
SELECT/INSERT也陆续变成同样状态，形成雪崩 -
information_schema.INNODB_TRX里查不到长事务，但performance_schema.threads里能看到活跃会话持有MDL
如何快速定位哪个会话在持锁不放
不能只看INNODB_TRX，MDL锁和事务不完全绑定：自动提交语句也会短暂持锁，连接池未关闭游标、框架隐式开启事务、甚至某些ORM的“读已提交”预热查询，都可能留下MDL S锁。
实操建议：
- 查
performance_schema.metadata_locks（MySQL 5.7+），过滤目标表名：SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_DURATION, LOCK_STATUS, OWNER_THREAD_ID FROM performance_schema.metadata_locks WHERE OBJECT_NAME = 'your_table';
- 关联
performance_schema.threads找线程归属：SELECT t.PROCESSLIST_USER, t.PROCESSLIST_HOST, t.PROCESSLIST_INFO FROM performance_schema.threads t JOIN performance_schema.metadata_locks m ON t.THREAD_ID = m.OWNER_THREAD_ID WHERE m.OBJECT_NAME = 'your_table' AND m.LOCK_STATUS = 'PENDING';
- 重点盯
LOCK_DURATION = 'TRANSACTION'的记录——这种锁生命周期和事务一致，最危险
ALGORITHM=INPLACE或LOCK=NONE为什么还是阻塞
这两个参数只影响物理数据操作阶段是否锁表，但DDL的元数据变更阶段（打开表、更新数据字典、写binlog）始终需要短暂的X MDL锁。如果此时已有事务持有S锁，它照样得排队等。
关键点：
-
ALGORITHM=INPLACE≠ 不需要MDL锁，只是DML可并发执行 -
LOCK=NONE≠ 不等待MDL，只是不阻塞DML，仍需等已有MDL释放 - MySQL 8.0.12之前，哪怕只是
MODIFY COLUMN name VARCHAR(255)，也可能触发全表COPY，进一步延长X锁持有时间
为什么KILL一个会话有时无效
因为被KILL的线程可能正处于“不可中断等待”状态：它已经发出了MDL请求，正在内核层等待锁释放，此时KILL只能标记为“待终止”，必须等它从等待队列中被唤醒并检查状态后才真正退出——这个过程可能长达几十秒甚至几分钟，尤其当锁被一个长时间未提交的事务持有时。
更稳妥的做法：
- 先确认持锁者是否可控（比如是运维脚本、测试连接、开发调试会话）
- 优先联系对应负责人手动
COMMIT或ROLLBACK，比暴力KILL快得多 - 若必须强杀，用
KILL CONNECTION {id}而非KILL QUERY {id}，后者只中断当前语句，不结束事务
最容易被忽略的一点：MDL锁的持有者未必是SHOW PROCESSLIST里显示Query状态的会话——它可能是Sleep状态但事务未提交，也可能是连接池里“空闲但未归还”的连接。盯住PROCESSLIST_TIME和TRX_STARTED时间戳比看状态更重要。
