卡死不是因为alter table本身慢，而是有其他连接正拿着s mdl锁不放；必须先定位并终止那个长事务，否则所有ddl和dml都会持续排队。
直接结论：卡死不是因为ALTER TABLE本身慢，而是有其他连接正拿着S MDL锁不放；必须先定位并终止那个长事务，否则所有DDL和DML都会持续排队。
看到Waiting for table metadata lock就该查谁在持锁
这个状态出现在SHOW PROCESSLIST里，说明已有线程被阻塞，但它只是“受害者”。真正的问题源头是另一个持有SHARED_READ或SHARED_WRITE MDL锁的连接——它可能早已COMMAND = 'Sleep'，但事务仍处于RUNNING状态。
别只盯着TIME大的等待线程，重点找这些特征：
-
COMMAND = 'Sleep'且STATE为空或NULL，但TIME > 600 -
INFO列为空（典型应用连接池归还连接但没COMMIT） - 对应
INNODB_TRX.trx_state = 'RUNNING'且trx_started远早于当前时间
用sys.schema_table_lock_waits一眼看清阻塞链
MySQL 5.7+ 自带这个视图，不用拼JOIN，直接暴露谁堵了谁：
SELECT * FROM sys.schema_table_lock_waits\G
关键字段：
-
blocking_pid：持有锁的连接ID（真凶） -
waiting_pid：被卡住的ALTER或SELECT（受害者） -
sql_text：持锁线程最后执行的语句（常为空，但有时能定位到BEGIN位置）
如果返回为空，先确认：SELECT @@performance_schema;是否为1，再检查performance_schema.setup_instruments中wait/lock/metadata/sql/mdl是否ENABLED = 'YES'。
查performance_schema.metadata_locks确认锁类型和持续时间
这个视图能告诉你锁是不是事务级的，避免误判：
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_DURATION, 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_TYPE = 'SHARED_READ'：通常是SELECT或mysqldump引起的 -
LOCK_DURATION = 'TRANSACTION'：锁会持续到事务结束，哪怕只跑了一条SELECT -
PROCESSLIST_ID：可直接对应到PROCESSLIST里的ID，用于KILL
杀之前务必确认事务没在写数据
别一看到trx_mysql_thread_id就KILL。先查它有没有改过行：
SELECT trx_id, trx_state, trx_isolation_level, trx_rows_modified FROM information_schema.innodb_trx WHERE trx_mysql_thread_id = ?;
如果trx_rows_modified > 0，说明有未提交的DML，KILL会触发回滚——大事务回滚可能耗时几分钟，反而延长阻塞。
更稳妥的做法是：
- 用
SHOW ENGINE INNODB STATUS\G搜索该trx_id，看mysql tables in use和locked tables段落 - 确认
trx_query为空且长时间无新操作，再执行KILL - 若不确定，优先联系对应应用方确认该连接是否可中断
最常被忽略的一点：REPEATABLE READ隔离级别下，事务从BEGIN起就持有MDL读锁，哪怕只执行过一次SELECT——这种隐式持锁很难从INFO列发现，必须靠trx_started和COMMAND = 'Sleep'交叉判断。
