必须先定位真正持有MDL锁的源头会话再KILL，而非杀显示“Waiting for table metadata lock”的等待线程；优先查performance_schema.metadata_locks中LOCK_STATUS='GRANTED'且LOCK_DURATION='TRANSACTION'的行，关联threads获取PROCESSLIST_ID后执行KILL强制断连以触发回滚释放锁。
DDL卡住时KILL无效，大概率是杀错了线程
执行KILL后DDL仍卡在Waiting for table metadata lock，不是命令没生效，而是你KILL的是等待方——那个显示ALTER TABLE的线程。它只是受害者，真正持锁的是另一个“安静”的连接。
常见错误现象：
- SHOW PROCESSLIST里看到ALTER线程状态是
Waiting for table metadata lock，顺手KILL了它，结果几秒后又冒出来（因为应用重试） - 查
INNODB_TRX发现没长事务，就以为没锁源，其实持锁者TRX_QUERY为空、COMMAND是Sleep、TIME却几百秒
必须转向performance_schema.metadata_locks查真实持锁者：
- 先确认采集已开：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl'; - 查目标表持锁会话（替换
your_db和your_table）：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_DURATION = 'TRANSACTION'且LOCK_TYPE为SHARED_READ或SHARED_WRITE的行——对应PROCESSLIST_ID才是该KILL的线程
为什么KILL QUERY对MDL阻塞完全没用
KILL QUERY只中断当前语句，事务不结束，MDL锁不释放。而DDL卡住的根本原因是事务级MDL锁（LOCK_DURATION = 'TRANSACTION'）一直挂着。
使用场景：
- 线程正在跑一个慢
SELECT，且你确认它不涉及事务控制（比如autocommit=1），可先试KILL QUERY观察3秒内是否退回到Sleep - 但只要
INNODB_TRX.TRX_STATE = 'RUNNING'且TRX_STARTED很早，就必须用KILL（等价于KILL CONNECTION）触发回滚
参数差异：
-
KILL QUERY：停语句，事务继续，锁还在thread_id -
KILL或thread_idKILL CONNECTION：断连→回滚→释放所有MDL + 行锁thread_id
MySQL 8.0+ 可直接用sys.schema_table_lock_waits省事
不用手拼metadata_locks和threads，系统视图已经帮你关联好了。
执行：SELECT * FROM sys.schema_table_lock_waits\G
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
关键字段：
-
BLOCKING_PID：直接就是该KILL的PROCESSLIST_ID -
BLOCKING_LOCK_TYPE：通常是SHARED_READ_ONLY，说明是长事务或mysqldump在读表 -
SQL_KILL_BLOCKING_CONNECTION：字段值就是现成的KILL NNN命令，复制执行即可
注意：这个视图在MySQL 8.0.16+默认可用；若提示不存在，先确认sys库已安装（mysql -e "source /usr/share/mysql/sys_schema.sql"）。
从库SQL线程卡住，别碰SQL_THREAD本身
Slave上SHOW SLAVE STATUS\G显示Slave_SQL_Running_State: Waiting for table metadata lock，问题不在复制线程，而在从库本地某个会话占着锁。
容易踩的坑：
- 执行
STOP SLAVE; START SLAVE;——只是让SQL线程重试，锁源还在，立刻再卡 - 误KILL
SQL_THREAD（Id通常为slave_sql）——会导致复制中断，甚至GTID错乱
正确做法：
- 查持锁者：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table'; - 关联
threads拿到PROCESSLIST_ID，再查information_schema.INNODB_TRX确认是否为长事务 - 执行
KILL（不是pidKILL）SQL_THREAD_ID
复杂点在于：从库上一个未提交的SELECT FOR UPDATE、一个卡住的mysqldump --single-transaction、甚至主库刚发来的一批并发DML正在回放，都可能持有MDL读锁，而DDL必须等它们全结束才能拿写锁——这中间没有超时机制，innodb_lock_wait_timeout对MDL完全无效。
