必须用KILL CONNECTION而非KILL QUERY，因后者不终止事务、不释放锁；需用具备PROCESS和SELECT权限的账号查INNODB_TRX定位长事务，TRX_STARTED超30秒即预警；KILL后状态为Killed属正常，回滚耗时可达正向操作3–5倍，锁仍被占用。
必须用 KILL CONNECTION，不能只用 KILL QUERY —— 后者不停事务、不放锁、业务照堵。
查不到长事务？先确认权限和表访问路径
执行 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX 返回空，不等于没长事务。常见原因是：当前账号没 PROCESS 和 SELECT 权限，连 INFORMATION_SCHEMA.PROCESSLIST 都看不全。必须用 root 或明确授过这两个权限的账号登录。另外，INNODB_TRX 不显示 autocommit=1 的单条语句、也不收录只读事务——所以别只盯这张表。重点看 TRX_STARTED 时间戳，生产建议阈值设为 30 秒，不是 10 分钟。
KILL CONNECTION 还是 KILL TRANSACTION？看 MySQL 版本和锁关系
MySQL 5.7+ 支持 KILL TRANSACTION <code>TRX_ID，它只终止事务本身，连接保活，适合 HikariCP 等连接池场景；5.6 及更早版本只能退而求其次用 KILL QUERY <code>thread_id，但它不结束事务，TRX_STATE 仍为 RUNNING 或 LOCK WAIT，锁不会释放。严禁对 TRX_WAITING_TRX_ID IS NOT NULL 的等待方执行 KILL CONNECTION——这会让持锁者继续跑，其他请求照堵。正确顺序是：从 INNODB_LOCK_WAITS 找出 BLOCKING_TRX_ID → 关联 INNODB_TRX 拿到对应 TRX_MYSQL_THREAD_ID → 再 KILL TRANSACTION 或 KILL CONNECTION。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
KILL 后锁还在？不是失败，是回滚在后台跑
执行 KILL CONNECTION <code>thread_id 后，SHOW PROCESSLIST 显示状态为 Killed 是正常现象，不代表锁已释放。InnoDB 必须按 undo log 逆向回滚，耗时 ≈ 正向操作的 3～5 倍。小事务（几行更新）通常 100ms 内完成；大事务（如百万行 UPDATE）可能卡在 Rolling back 状态数分钟。此时锁仍被占用，新请求继续排队。若发现 kill 后锁“一直不放”，先查 INNODB_TRX 中该事务的 TRX_OPERATION_STATE 是否为 rolling back，再看 TRX_ROWS_MODIFIED 估算剩余工作量。
最易被忽略的是：KILL 命令发出后，你无法控制回滚速度，也不能中断回滚过程。它完全由 InnoDB 引擎异步执行，期间连接已断、线程已消，但锁资源仍在占用中——这点和直觉相反，也是线上误判“kill 失败”的主因。
