必须先查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 thread_id 后，TRX_STATE 仍为 RUNNING 或 LOCK WAIT，行锁/MDL 锁继续生效
• KILL CONNECTION thread_id 才触发强制回滚，InnoDB 释放所有锁，并从 INNODB_TRX 中移除该事务记录
• MySQL 5.7+ 中 KILL id 等价于 KILL CONNECTION 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 重新取值，不能缓存、不能凭印象。