KILL后线程卡在Killed状态是因为它仅设置中断标记，需线程在安全检查点主动响应；若卡在不可中断位置（如等待InnoDB并发席位、大事务回滚中、MyISAM修复、INNODB_BUFFER_POOL_PAGES_INDEX读取等），则无法立即退出。
为什么KILL后线程卡在Killed状态不消失
因为KILL不是强制终止操作系统线程，而是设置一个中断标记（killed标志），线程必须自己在安全检查点主动响应。如果线程正卡在不可中断的位置——比如等待进入InnoDB执行队列、持有MDL读锁未释放、或正在刷盘但尚未到达检查点——它就无法立刻退出。
- 常见卡点包括：
innodb_thread_concurrency设为非0时，线程可能在“等待获取InnoDB并发席位”循环中，全程不查killed标志 - 大事务回滚中（
trx_state: ROLLING BACK），SHOW PROCESSLIST显示Killed是正常现象，实际清理仍在后台进行 - MyISAM表上执行
REPAIR TABLE或OPTIMIZE TABLE时，可能因引擎不支持事务而无法安全中止，导致Killed长期挂起 - 从
INFORMATION_SCHEMA.INNODB_BUFFER_POOL_PAGES_INDEX这类内部表读取时，曾有案例卡死在InnoDB底层锁逻辑中，永远无法返回检查点
KILL CONNECTION后锁还没释放？不是失败，是回滚没完
执行KILL CONNECTION <code>thread_id后，事务确实已触发回滚，但InnoDB的回滚是异步且耗时的：每回滚一行都要写undo日志、更新页、释放行锁和间隙锁。若trx_rows_modified值很大（比如50万+），回滚可能持续数分钟甚至更久。此时SHOW PROCESSLIST里看不到该连接，但SELECT * FROM information_schema.INNODB_TRX仍能看到trx_state: ROLLING BACK。
-
trx_rows_modified字段下降趋势可判断回滚进度；归零即锁释放完成 - 重启MySQL不能跳过回滚——它会强制在启动时继续执行未完成的回滚，否则数据不一致
- 别用
KILL QUERY试图解决锁问题：它只停语句，事务仍活跃，锁照常持有
如何确认是真卡死，还是只是慢回滚
先查information_schema.INNODB_TRX，重点看trx_state和trx_operation_state：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 若
trx_state = 'ROLLING BACK'且trx_operation_state含rollback，说明回滚正在进行，耐心等 - 若
trx_state = 'RUNNING'但PROCESSLIST.State = 'Killed'，大概率是线程卡在检查点之外（如等待MDL、阻塞在innodb_thread_concurrency队列） - 若
trx_state = 'LOCK WAIT'却显示Killed，说明KILL发给了等待方而非持锁方——这是典型误操作，持锁者还在跑，堵得更死
真正“杀不死”的线程，往往和MDL或并发控制有关
最隐蔽的Killed僵局，来自元数据锁（MDL）和innodb_thread_concurrency协同作用。例如当innodb_thread_concurrency = 2，而3个线程同时争抢InnoDB资源时，被KILL的那个可能永远卡在“等待轮到自己进引擎”的while循环里，既不响应中断，也不释放MDL读锁——因为退出逻辑根本没机会执行。
- 这种场景下，
KILL CONNECTION无效，SHOW PROCESSLIST里状态长期为Killed，INNODB_TRX里甚至查不到对应事务 - 唯一可靠解法：临时调高
innodb_thread_concurrency（如设为0或100），让卡住的线程能进入检查点并响应KILL - 事后必须检查应用层连接池配置（如HikariCP的
maxLifetime），避免长连接复用导致MDL锁长期滞留
真正的难点不在怎么发KILL，而在发完之后——你得知道它卡在哪一层，以及那一层是否允许被中断。
