mysql行锁无法直接手动释放，必须通过kill connection终止持有锁的事务，待其回滚完成后锁才真正释放；需借助innodb_trx和innodb_lock_waits定位持锁者，严禁使用kill query。
行锁不能被手动释放，kill 连接只是间接解法
MySQL 的 InnoDB 行锁没有 UNLOCK ROWS 或类似语句，也没有 API 能单独释放某一行上的锁。所谓“手动释放行锁”，本质是终止持有锁的事务——而最常用、最直接的方式就是 kill 掉对应连接。但要注意：kill 不等于立即解锁，它触发的是连接中断和事务回滚，真正释放锁发生在回滚完成之后。
KILL CONNECTION 后行锁何时真正释放？
执行 KILL CONNECTION <id></id> 后，MySQL 会向目标连接发送中断信号。该连接对应的事务进入“回滚中”状态，此时行锁仍被占用，其他事务继续等待。只有当回滚操作物理完成（尤其是大事务可能耗时数秒甚至分钟），锁才真正释放。
- 小事务（几行更新）：通常在 100ms 内完成回滚并释放锁
- 大事务（大量 UPDATE/DELETE）：回滚时间 ≈ 正向操作耗时，期间锁持续存在
- 若被 kill 的连接处于
Sleep状态但事务未提交（即 autocommit=0 且没 COMMIT/ROLLBACK），kill 会直接回滚，释放速度取决于 undo log 大小 - 若连接已卡死（如网络断开但 MySQL 还没检测到），需配合
wait_timeout或interactive_timeout参数才能最终清理
如何精准定位并 kill 持有行锁的连接？
不能靠猜，得从锁等待链入手。先查谁在等锁，再顺藤摸瓜找到持锁者：
SELECT * FROM information_schema.INNODB_TRX\G
重点关注 TRX_STATE（是否 RUNNING/WAITING）、TRX_STARTED（事务开始时间）、TRX_QUERY（当前 SQL）；
SELECT * FROM information_schema.INNODB_LOCK_WAITS\G
拿到 BLOCKING_TRX_ID，再关联 INNODB_TRX 查出持锁事务的 TRX_MYSQL_THREAD_ID；
最后用 KILL CONNECTION <thread_id></thread_id> 终止——注意不是 KILL QUERY，后者只停当前语句，事务仍在，锁不释放。
容易踩的坑：kill 之后锁还在？
常见误解是 “kill 就等于锁立刻消失”，实际不是。以下情况会导致 kill 后锁延迟释放甚至看似“无效”：
- 事务正在回滚大表更新，你看到
SHOW PROCESSLIST里状态是Rolling back，此时锁仍被占用 - 持锁连接已被 kill，但下游应用重连后又执行了相同逻辑，形成新锁等待链
- 误 kill 了等待方而非持锁方，结果等锁的连接没了，但持锁事务还在跑，其他连接继续堵着
- 使用了
KILL QUERY <id></id>，事务没结束，TRX_STATE仍是LOCK WAIT或RUNNING，行锁照常持有
真正棘手的永远不是怎么 kill，而是为什么这个事务迟迟不提交——比如应用层漏了 commit、SQL 中有隐式事务、或代码卡在外部调用（HTTP、RPC）上。锁本身只是症状，根因在业务逻辑和连接生命周期管理。
