waiting for table metadata lock 是 alter table 在等待 mdl_exclusive 锁，因其他连接持有 shared_read 或 shared_write 锁未释放；常见于未提交事务、长事务或异常退出连接；需通过 performance_schema.metadata_locks 和 innodb_trx 联合定位持锁线程，优先 kill query 再考虑 kill。
Waiting for table metadata lock 不是表被锁死了，而是你的 ALTER TABLE 操作卡在等一个排他元数据锁（MDL），而这个锁正被别的连接悄悄攥着不放。
为什么ALTER TABLE必须等MDL_EXCLUSIVE？
MySQL 对表结构的修改（比如加字段、改类型）必须确保期间没人读/写这张表的元信息——否则会破坏一致性。所以 ALTER TABLE 会尝试获取 MDL_EXCLUSIVE 锁，但它和任何已存在的 MDL_SHARED_READ 或 MDL_SHARED_WRITE 锁互斥。
常见触发场景：
- 某个连接执行过
SELECT * FROM t，但autocommit=0且没COMMIT或ROLLBACK，它就一直持着SHARED_READ - 一个长事务正在跑
UPDATE或INSERT，哪怕只涉及几行，也会持有该表的SHARED_WRITE - 应用异常退出后连接没关闭，但事务状态仍为
RUNNING，锁还在
为什么SHOW PROCESSLIST找不到真正持锁者？
SHOW PROCESSLIST 只显示线程当前动作状态，不反映锁持有关系。一个 Command = 'Sleep'、Time = 1200、Info = NULL 的连接，很可能就是罪魁祸首——它早已执行完语句，但事务没结束，MDL 锁没释放。
必须查 performance_schema.metadata_locks：
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS, PROCESSLIST_ID FROM performance_schema.metadata_locks m JOIN performance_schema.threads t ON m.OWNER_THREAD_ID = t.THREAD_ID WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table' AND LOCK_STATUS = 'GRANTED';
重点看 LOCK_STATUS = 'GRANTED' 的行，对应 PROCESSLIST_ID 就是真正在 hold 锁的线程 ID。
如何确认那个“Sleep却RUNNING”的悬挂事务？
单靠 INNODB_TRX 可能漏掉已断连但未清理的事务；单靠 PROCESSLIST 又容易把空闲连接当嫌疑对象。要联合查：
SELECT t.trx_id, t.trx_started, t.trx_state, p.ID, p.USER, p.HOST, p.COMMAND, p.TIME, p.INFO FROM information_schema.INNODB_TRX t JOIN information_schema.PROCESSLIST p ON t.trx_mysql_thread_id = p.ID WHERE p.COMMAND = 'Sleep' AND t.trx_state = 'RUNNING' ORDER BY t.trx_started;
如果 trx_started 是 20 分钟前，COMMAND 是 Sleep，INFO 为空，基本可以确定：它开了事务，啥也没干，就卡在这儿占着 MDL。
KILL之前先试KILL QUERY，别一上来就杀连接
直接 KILL [thread_id] 会强制回滚整个事务，如果它已写了大量数据，回滚可能持续几分钟甚至更久，期间依然阻塞其他操作。
更稳妥的做法：
- 先
KILL QUERY [thread_id]：只中断当前语句，事务还活着，但锁通常会释放（尤其对纯 SELECT 场景） - 观察
ALTER TABLE是否开始执行；如果没反应，再KILL [thread_id] - 注意：Python 的
pymysql或aiomysql默认autocommit=False，脚本里只查不提交 + 不 close()，就是典型隐患源
真正的难点不在怎么 kill，而在怎么快速从一堆 Sleep 连接里揪出那个“安静但致命”的事务——它不报错、不打日志、不占 CPU，只默默卡住所有 DDL 和后续查询。
