必须先查INNODB_TRX获取TRX_MYSQL_THREAD_ID，再执行KILL CONNECTION；仅凭SHOW PROCESSLIST或TIME排序易误杀等待者，因持锁线程常表现为Command='Sleep'且TRX_STATE='RUNNING'，而等待者State多为Waiting for lock。
必须先定位真正持锁的线程 ID（TRX_MYSQL_THREAD_ID），再执行 KILL CONNECTION；只看 SHOW PROCESSLIST 或按 TIME 排序杀，大概率误杀等待者，锁反而更堵。
怎么找真正在 hold lock 的线程，而不是等锁的替罪羊
阻塞链里永远有“持有者”和“等待者”。SHOW PROCESSLIST 默认只显示等待方（State 是 Waiting for table metadata lock、Waiting for row lock 或 Locked），但它们不是该杀的对象。
- 必须运行
SHOW FULL PROCESSLIST：否则Info列被截断，看不到完整 SQL，无法判断是否是大事务或 DDL - 重点盯
Command = 'Sleep'且Time > 30的连接：这种“假空闲”最危险——事务没提交，锁还挂着，但 PROCESSLIST 里毫无提示 - 查
INFORMATION_SCHEMA.INNODB_TRX才能确认真实状态：TRX_STATE = 'RUNNING'+TRX_STARTED时间远早于现在，说明它才是持锁源头 - 别信
PROCESSLIST.ID：要杀的是TRX_MYSQL_THREAD_ID，它和PROCESSLIST.ID可能不一致
为什么不能用 KILL QUERY，必须用 KILL CONNECTION
KILL QUERY 只中断当前语句，事务不结束，锁不释放。对已持锁的长事务，它等于什么都没做。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
KILL QUERY <code>thread_id后，TRX_STATE仍为RUNNING或LOCK WAIT，行锁/MDL 锁继续生效 -
KILL CONNECTION <code>thread_id才触发强制回滚，InnoDB 释放所有锁，并从INNODB_TRX中移除该事务记录 - MySQL 5.7+ 中
KILL <code>id等价于KILL CONNECTION <code>id，但显式写全更安全、可读 - 严禁对
TRX_WAITING_TRX_ID IS NOT NULL的等待方执行KILL CONNECTION——这会让持锁者继续跑，其他连接照堵
kill 后锁还在？不是失败，是回滚在后台跑
执行 KILL CONNECTION 后，SHOW PROCESSLIST 显示状态为 Killed 是正常现象，不代表事务已结束。
- InnoDB 回滚耗时通常是正向操作的 3–5 倍：几行 UPDATE 回滚很快；百万行 UPDATE 可能卡在
Rolling back状态几分钟 - 务必再查
INNODB_TRX中该事务的TRX_OPERATION_STATE是否为rolling back，并结合TRX_ROWS_MODIFIED估算剩余工作量 - 若发现 kill 后锁“一直不放”，优先确认是不是回滚本身太重，而不是命令没生效
- 回滚期间新请求仍会排队，这不是异常，是 InnoDB 的原子性保证机制
真正容易被忽略的是：TRX_MYSQL_THREAD_ID 不等于 PROCESSLIST.ID，也不等于你看到的 SHOW ENGINE INNODB STATUS 里的事务 ID；每次 kill 前必须用 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX 重新取值，不能缓存、不能凭印象。
