事务与MVCC：死锁检测与处理

可视化演示

展示等待图环路检测死锁、超时检测机制触发回滚及牺牲者选择策略，交互切换理解数据库死锁检测与处理核心流程。

死锁成因剖析

深夜环形停车场，T1 占了 1 号位、还想进 2 号位；T2 占了 2 号位、还想要 3 号位；T3 占了 3 号位、盯上 4 号位；T4 占了 4 号位、偏偏要回 1 号位。四辆车首尾相接，每辆车的路都被下一辆堵住。停车场管理员跑过去一看就明白了：这不是谁技术差，而是大家互相攥着对方要的东西不放——这就是死锁的雏形。

数据库里，事务就是司机，行锁就是车位。事务 A 更新了第 1 行（拿着 1 号位），还想更新第 2 行；事务 B 更新了第 2 行还想更新第 3 行……一旦形成一个“你等我、我等他”的圆圈，谁都无法前进。专业定义是：两个及以上事务在并发执行中，各自持有一个资源，又都在等待对方持有的资源，导致所有事务永久阻塞，称为死锁。

死锁的发生有四个必要条件：互斥、持有并等待、不可抢占、循环等待。四者同时满足才会死锁，因此所有检测与处理策略的本质，都是围绕打破其中之一做文章。比如“主动避免策略”就是打破循环等待。公式如下：

所以管理者心里有本账：只要让四辆车别“无限期攥着车位不放”，或者别让它们形成圆圈，就能从根上防住死锁。后文讲的检测、超时、回滚、排序，都是从这个思路长出来的。

等待图检测法

与急脾气的管理员不同，MySQL InnoDB 的管理员很精细——他在监控室挂一块白板，每当一辆车说“我等 X 车位”，就画一条从这辆车指向车位持有者的箭头。这块白板，就是等待图。箭头越多，白板上的关系越复杂，但只要箭头构成一个圈，管理员立刻就能判断：出事了。

数据库的等待图是有向图 $G_t=(V,E)$，其中 $V$ 是所有活跃事务，$E$ 是等待关系：$T_i \to T_j$ 表示 $T_i$ 在等 $T_j$ 持有的锁。事务申请锁时加一条边，获取锁或回滚时删一条边。只要途中出现有向环，就必然存在死锁。InnoDB 的做法是：每次产生新的等待边时，增量检查一次图中有没有环，属于“实时检测”。

环检测用深度优先搜索（DFS）：从任意顶点出发递归遍历，如果当前顶点的某个邻居已经在“本次递归路径栈”里，说明绕了一圈又回到自己，即找到环。等待图的数学定义与判定条件如下：

管理员盯着白板，箭头一旦绕成一圈，他就立刻抓起喇叭喊：“死锁！” 这种检测方式不依赖猜测，只要图里有环就一抓一个准，这也是主流数据库的核心检测思路。

等待超时策略

有些简单的停车场，管理员不看白板，只发计时小票：每辆车进入等待状态就掐表，等待超过一定秒数，不管是不是真死锁，直接请出场。这就是等待超时策略。它的逻辑非常直白——僵持太久的一定有问题，先赶走再说。

数据库里，innodb_lock_wait_timeout 就是锁等待超时参数，默认 50 秒。一个事务等待某个行锁超过该时长，数据库就让这个事务报错并回滚。优点是实现简单，不依赖任何图结构；缺点也很明显：正常的长时间事务（比如跑大报表、批量更新几百万行）可能只是排队等锁等得久，却被误判成死锁杀掉，这就是“误杀长事务”。

超时判定的公式可以写成：

急脾气管理员虽然果断，但容易误伤老实车。所以现代数据库通常把等待超时当成“兜底保险”：先用等待图精准检测，万一检测机制出问题或事务卡住，再由超时机制断后。

受害者选择

管理员确认死锁后，必须请一辆车退出去。请谁呢？T1 已经卸了半车货，T4 才刚停进去——当然是请 T4 退，损失最小。这个“损失最小”就是受害者选择的直觉：不是惩罚谁，而是让整个停车场付出的代价最低。

数据库里，InnoDB 实际会选择“undo log 行数最少”的事务回滚，近似理解为“已完成工作最少、回滚最便宜”的事务。更通用的代价函数可以综合三个因素：事务已运行时长 $A$、已完成的更新行数 $W$、已持有的锁数量 $R$，再给它们配上不同的权重系数。计算公式如下：

选定受害者之后，还要决定回滚到什么程度。默认是“全车倒出”——整个事务回滚，所有修改作废；有些数据库支持保存点（Savepoint），可以只回滚到保存点，保留之前的工作，这就是“回滚粒度”的差别。管理员专挑损失最小的车请走，整体代价最低，这就是死锁处理的核心智慧。

主动避免策略

如果管理员更负责，他会规定所有车进入停车场后必须按“车位号从小到大”的顺序停靠：先找 1 号位、再去 2 号位、最后 3 号位。这样一来，四辆车都朝着同一个方向行驶，永远不可能绕成环。与其等死锁发生后再手忙脚乱地处理，不如从规则上让它根本发生不了。

数据库里的对应做法是“资源统一排序”（Lock Ordering）：所有事务严格按照同一全局顺序获取资源。比如在代码里约定，操作多条记录时一律按主键 ID 升序加锁，先锁 id=1 再锁 id=2，而不允许某个事务先锁 id=2 再锁 id=1。这个规则直接打破了“循环等待”这一必要条件。公式化表达为：

除了资源排序，还有一种“一次性获取”的思路：把多条记录的加锁合并到一条 SELECT ... FOR UPDATE 或 UPDATE 语句中，让数据库在一瞬间同时拿到所有需要的锁，而不是逐个申请。再配合锁超时兜底，即使有事务违背约定，也不会无限期卡死。规矩定好了，环自然断。

数据库实现对比

不同停车场的规矩各不相同。MySQL InnoDB 的管理员眼疾手快，白板上一出现环就立刻处理；PostgreSQL 的管理员按固定节奏巡场，每隔一小段时间检查一次，发现死锁就向司机报错；SQL Server 管理员则每几秒做一次全面扫描，还会给每辆车标一个“牺牲优先级”，决定先请谁出场。

技术层面看：MySQL 的 InnoDB 在等待边发生变化时即时增量检测，回滚 undo 最少的事务，可用 innodb_deadlock_detect 参数开关检测功能；PostgreSQL 的锁管理器周期性检查进程间的等待关系，检测到死锁后终止其中一个事务，并向客户端返回 "deadlock detected" 错误；SQL Server 的死锁监视器周期扫描锁等待，支持用 SET DEADLOCK_PRIORITY 指定事务的牺牲优先级，并将死锁图写入错误日志供分析。

检测频率越高，发现越及时，但 CPU 开销也越大。单次环检测的复杂度是 $O(V+E)$，$V$ 是等待图的顶点数，$E$ 是边数；假设每秒检测 $f$ 次，总开销就是两者的乘积：

选哪种方案完全看业务：高并发电商系统更看重快速解除僵局，愿意为实时检测付出 CPU 成本；离线分析系统死锁极少，用低频率周期检测就足够省心。

性能调优实践

管理员最终的考核标准是运营报告：停车场每晚堵死几次？每次回滚了几辆车？他需要一套指标和工具来持续监控。数据库运维也是同样道理，光会处理死锁不够，还要会量化、会调优。

常见的指标是死锁率（Deadlock Rate），定义为一个时间段内死锁次数与总事务数的比值。优化手段包括：一是缩短事务——事务越短，持锁时间越短，死锁概率越低；二是统一加锁顺序，避免应用层代码各行其是；三是减小锁范围，让 SQL 走索引、少扫行；四是在 MySQL 中调整 innodb_deadlock_detect 和 innodb_lock_wait_timeout 参数；五是查看 SHOW ENGINE INNODB STATUS 中的最近死锁日志，分析等待环后调整 SQL。死锁率公式如下：

管理者心中有指标、手里有工具，停车场就不会再彻夜堵车。从“出事了再抓环”到“让环根本形成不了”，死锁检测与处理这门功夫，最终都落在“让数据库在高并发下依然稳定可用”这一个目标上。

AI 应用场景

Python 演示

class DeadlockDetector:    """使用等待图检测死锁，并选择最小代价事务回滚。"""     def __init__(self):        self.wait_graph = {}      # 等待图: txn_id -> set of holder_ids        self.transactions = {}    # 事务元数据: txn_id -> {"age","work","locks"}     def add_txn(self, txn_id, age, work, locks):        self.transactions[txn_id] = {"age": age, "work": work, "locks": locks}        self.wait_graph.setdefault(txn_id, set())     def add_wait(self, waiter, holder):        self.wait_graph.setdefault(waiter, set()).add(holder)     def remove_wait(self, waiter, holder):        self.wait_graph.get(waiter, set()).discard(holder)     def detect_cycle(self):        visited = set()        path = []         def dfs(node):            visited.add(node)            path.append(node)            for nxt in self.wait_graph.get(node, ()):                if nxt not in visited:                    if dfs(nxt):                        return True                elif nxt in path:                    idx = path.index(nxt)                    self.cycle = path[idx:] + [nxt]                    return True            path.pop()            return False         for txn in list(self.wait_graph):            if txn not in visited:                if dfs(txn):                    return self.cycle        return None     def choose_victim(self, cycle):        # 回滚代价 = 已完成工作量 + 已持锁数量，越小越划算        def cost(txn_id):            t = self.transactions[txn_id]            return t["work"] + t["locks"]        return min(cycle, key=cost)     def resolve(self):        cycle = self.detect_cycle()        if not cycle:            return None        victim = self.choose_victim(cycle)        # 回滚受害者：释放它持有的资源，并删除与它相关的等待边        del self.transactions[victim]        self.wait_graph.pop(victim, None)        for holder_set in self.wait_graph.values():            holder_set.discard(victim)        return victim  def simulate():    d = DeadlockDetector()    # age, work, locks 分别代表运行时长、已更新行数、已持锁数量    for i, age in enumerate([10, 20, 30, 5], start=1):        d.add_txn("T%d" % i, age, work=i * 2, locks=1)     # 构成环: T1->T2->T3->T4->T1    d.add_wait("T1", "T2")    d.add_wait("T2", "T3")    d.add_wait("T3", "T4")    d.add_wait("T4", "T1")     cycle = d.detect_cycle()    print("检测到死锁环:", " -> ".join(cycle) + " -> " + cycle[0])    victim = d.resolve()    print("选择回滚受害者:", victim)    print("回滚后等待边:", {k: sorted(v) for k, v in d.wait_graph.items() if v})  if __name__ == "__main__":    simulate()

1. self.wait_graph.setdefault(waiter, set()).add(holder)记录一条等待边：等待者指向持有者，对应白板上新增一个箭头。
2. elif nxt in path:DFS 时发现邻居已经在当前递归路径里，说明绕回了自己，这就是环。
3. self.cycle = path[idx:] + [nxt]从递归路径中截取从环起点到终点的一段，得到完整的死锁环。
4. return min(cycle, key=cost)在所有环内事务里挑代价最小者，对应停车场管理员请“损失最小”的车退场。
5. holder_set.discard(victim)受害者回滚后，从所有其他事务的等待集合中移除它，等待图不再指向它，死锁环随即断裂。

常见误区

面试题