MySQL执行Update卡死？排查锁表与释放线程

问题根源：隐式锁与事务机制

MySQL 默认情况下处于 AUTOCOMMIT=1 状态，即每条语句执行后自动提交。但当自动提交被设置为关闭（0 或 OFF），或者在应用代码中显式开启了事务但未闭合时，第一次 UPDATE 操作会获取该行数据的排他锁。此时，第二个针对同一行（或重叠范围）的 UPDATE 请求就会被挂起，表现为“卡死”，直到第一个事务结束或等待超时。

复现场景与排查步骤

第1步：确认自动提交设置

首先检查当前会话或全局的自动提交状态。执行以下 SQL：

SHOW VARIABLES LIKE 'autocommit';

若输出结果为 OFF 或 0，则需手动管理事务提交。你可以将其重新开启以恢复自动行为：

-- 开启自动提交
SET autocommit = ON;
-- 或直接设为1
SET autocommit = 1;

第2步：重现卡死状态（用于测试环境）

为了验证解决方案，可以在两个不同的数据库连接窗口中模拟冲突操作：

1. 窗口 A：执行更新并保持事务打开（不提交）：
   

   START TRANSACTION;
   UPDATE car SET color = '银色' WHERE id = 1;
   -- 注意：此处暂不执行 COMMIT

2. 窗口 B：尝试对同一记录执行更新：
   

   UPDATE car SET color = '红色' WHERE id = 1;

此时，窗口 B 的命令将一直等待，表现出“卡死”状态。

第3步：查询正在运行的事务与锁

在另一个连接或通过监控工具，查询 InnoDB 引擎的活动事务信息，定位阻塞来源：

SELECT * FROM information_schema.INNODB_TRX;

关注字段 trx_mysql_thread_id，它代表了持有锁的 MySQL 线程 ID。同时，可以查看锁等待情况：

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; -- 查看谁在等锁
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;     -- 查看当前锁持有者

通过对比，我们可以发现：
- 一个线程 ID（例如 1084）正在等待锁；
- 另一个线程 ID（例如 1089）正在执行未提交的更新操作，因此它是“罪魁祸首”。

第4步：强制终止阻塞线程

一旦确认了持有锁且长时间不提交的线程 ID，可以直接使用该 ID 杀掉进程，强制回滚事务并释放锁：

KILL 1089;

执行后，原本卡住的窗口 B 通常会抛出错误或获得所需的数据控制权，具体表现取决于客户端的超时设置。若未及时 KILL 持有锁的线程，第二个更新语句最终会因等待锁超时而报错退出。

其他辅助排查命令

除了上述 InnoDB 专用视图，还可以使用通用的进程列表查看数据库当前的活动连接：

SHOW PROCESSLIST;
-- 或者
SELECT * FROM information_schema.PROCESSLIST;

这有助于全面了解数据库负载和异常连接。

扩展：Oracle 中的类似操作

如果使用 Oracle 数据库，处理锁表和会话杀死的逻辑类似但语法不同：

1. 查询锁定记录的会话 SID 和 Serial#：
   

   SELECT s.sid, s.serial# 
   FROM v$locked_object lo, dba_objects ao, v$session s 
   WHERE ao.object_id = lo.object_id 
   AND lo.session_id = s.sid;

2. 删除/终止该会话：
   

   ALTER SYSTEM KILL SESSION 'SID,serial#';

总结

MySQL Update 卡死的核心在于事务锁的竞争。解决此类问题的关键在于及时识别并终止那些“僵尸”事务线程。日常开发中，建议在代码层面明确事务边界，或使用 SET autocommit=ON 避免手动管理带来的风险。以上就是 MySQL 执行 Update 卡死问题的详细内容，更多关于 MySQL 锁表排查与事务管理的资料请关注本站其它相关文章！