锁 · XB 现场笔记

InnoDB 死锁会回滚整个受害事务

Thu, 20 Apr 2028 00:00:00 +0000

当多个事务形成不兼容锁请求的等待环时，就发生 InnoDB 死锁。开启死锁检测后，引擎选择一个受害者，回滚它的整个事务，使其他参与者能够继续。应用收到错误 1213（SQLSTATE 40001）。若只重试报错的那条语句，就会漏掉同一事务中更早执行、但已经一起被回滚的工作。

坏掉的样子

不能给所有锁错误套用同一种回滚规则。默认关闭超时整笔回滚时，锁等待超时只撤销正在等待的那条语句，事务内此前执行的语句仍然待决。开启对应服务端选项后，超时才会改为回滚整个事务。死锁本来就会回滚整个受害事务，不能把默认超时的语句级行为误套在死锁上。

受害者选择也不保证某个固定会话永远输。应用必须检查真实错误，再以有界次数重试完整逻辑事务。不可逆的外部副作用如果没有单独去重契约，不应跟着数据库事务自动重放。提交回复途中连接断开，也不等于已经得到死锁回滚的确定结论；错误类型与已知事务结果需要分开判断。

快速验证

历史三会话测试保持原样；当前没有 MySQL 服务器，因此本次没有重跑。

在可丢弃的 MySQL 8.4 实例上打开甲、乙和观察者三个全新管理客户端，先确认三个会话均处于自动提交模式，关闭客户端自动重新连接，保持会话身份稳定。既有运行记录中的版本是 MySQL 8.4.11。观察者先创建尚未使用的实验模式，并核对死锁检测开启、超时采用默认语句级回滚：

CREATE DATABASE xbcatm_deadlock_lab;
USE xbcatm_deadlock_lab;
CREATE TABLE accounts (id INT PRIMARY KEY, balance INT NOT NULL) ENGINE=InnoDB;
INSERT INTO accounts VALUES (1,100),(2,100);
SELECT @@innodb_deadlock_detect,@@innodb_rollback_on_timeout;

两个设置应分别为一和零。甲开始一项给两个账户各增加十的操作，先锁住第一个账户：

USE xbcatm_deadlock_lab;
SET SESSION innodb_lock_wait_timeout=30;
SET @increment=10;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=1;

乙开始一项各增加一百的操作，先锁住第二个账户：

USE xbcatm_deadlock_lab;
SET SESSION innodb_lock_wait_timeout=30;
SET @increment=100;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=2;

甲再请求乙持有的那一行，此时语句会等待：

UPDATE accounts SET balance=balance+@increment WHERE id=2;

在甲的三十秒锁等待超时之前，乙执行反向请求：

UPDATE accounts SET balance=balance+@increment WHERE id=1;

其中一个会话收到死锁错误，把实际报错者认作受害者；另一个更新则会完成。下面的提交只在幸存会话中执行：

COMMIT;

观察者检查已经提交的状态：

SELECT id,balance FROM accounts ORDER BY id;

如果甲幸存，两行均为一百一十；如果乙幸存，两行均为二百。受害者更早的更新也已经消失。既有运行选择乙为受害者，最后看到两行一百一十。在受害者原来的会话中，用户变量仍然记录该操作的原始增量；现在按一致顺序取得两行，重试完整操作：

SELECT @increment;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=1;
UPDATE accounts SET balance=balance+@increment WHERE id=2;
COMMIT;

观察者核对组合结果：

SELECT id,balance FROM accounts ORDER BY id;

两行都必须变成二百一十。接下来对照锁等待超时。观察者先重置实验数据：

UPDATE accounts SET balance=100;

甲持有第一行的写锁：

START TRANSACTION;
UPDATE accounts SET balance=balance+1 WHERE id=1;

乙修改第二行，并设定较短等待时间：

SET SESSION innodb_lock_wait_timeout=1;
START TRANSACTION;
UPDATE accounts SET balance=balance+5 WHERE id=2;

仍在乙中请求甲持有的行：

UPDATE accounts SET balance=balance+5 WHERE id=1;

这次得到 1205（SQLSTATE HY000）锁等待超时错误，而不是死锁错误。乙检查自己事务里仍然待决的工作：

SELECT id,balance FROM accounts ORDER BY id;

乙读到一百和一百零五；观察者却仍然看到已提交的一百和一百：

SELECT id,balance FROM accounts ORDER BY id;

超时没有撤销乙此前增加的五。现在显式丢弃剩余事务，先在乙回滚：

ROLLBACK;

再在甲回滚：

ROLLBACK;

最后由观察者确认原始余额，并删除实验模式：

SELECT id,balance FROM accounts ORDER BY id;
DROP DATABASE xbcatm_deadlock_lab;

这项验证通过真实数据值区分回滚范围，而不只是相信错误消息里的文字。遇到不符合预期的结果就停止，先回滚仍然打开的实验事务，再进行清理。特别是超时之后不要直接提交残余操作，否则可能把业务操作的一部分留下，却误认为整笔工作已经失败并全部撤销。

减少等待环，但不假定它们消失

对共同业务资源采用一致的取得顺序，缩短事务，并使用合适索引，避免锁住超出操作需要的记录。范围操作与二级索引维护，还可能引入这个双主键行例子之外的锁交互。一致顺序能够减少已经识别的等待环，但不能证明所有可能的死锁都被移除，也不能替代错误发生之后的正确恢复逻辑。

可以通过引擎状态查看最近一次检测到的死锁；如果事件频率需要更长历史，应配置相应采集。把涉及的语句和锁顺序关联回完整应用事务，不要只盯着最后那条报错语句。重试应该在截止时间和尝试次数约束下重新执行完整工作，同时区分超时语义。最终还要核对业务结果，避免仅因为最后一次语句没有报错，就认为逻辑操作已经完整恢复。

来源

MySQL 8.4 InnoDB 错误处理，死锁整笔回滚与可配置的超时回滚范围，已核验 2026-09-12。
MySQL 8.4 死锁示例，复现等待环并检查实际受害者，已核验 2026-09-12。
MySQL 8.4 InnoDB 锁，并发操作涉及的记录锁与范围锁，已核验 2026-09-12。

事务拿锁时别的请求会礼貌等待

Wed, 16 Feb 2028 00:00:00 +0000

等待锁可能是正常协调，也可能让连接和请求持续排队。PostgreSQL 的 lock_timeout 可以让调用方停止等待，但它不会解释持锁者为什么慢，更不会自动决定业务是否可以重试。应从操作能够接受的延迟出发设定预算，同时找到实际阻塞者；单纯延长超时或增加尝试次数，可能只是扩大同一条等待队列。

坏掉的样子

锁超时分别作用于每一次锁获取尝试，包括语句隐式申请的锁。它测量的是等待当前锁的时间，而不是整条语句的总运行时间。查询已经执行了一段时间，随后又申请一把锁，仍然可能触发这个限制。反过来，多次较短的等待也可能累计超过一个配置间隔。把锁超时理解成“只有语句刚开始时检查一次”，或把它当成整次查询的总截止时间，都会漏掉真实的等待范围。

statement_timeout 限制整条语句执行，其中也包括等锁。如果它更短，可能先于锁超时取消语句。空闲事务会话超时处理的则是另一种状态：事务还开着，但服务器正在等待客户端发下一条命令。卡在更新内部等待锁的后端通常仍是活动状态，等待事件属于锁；不能看到连接排队，就直接把所有等待者叫作空闲事务。真正闲着不提交的持锁者和正在等待的受阻者，需要分别定位。

PostgreSQL 十八还提供事务超时，事务持续过久时会终止整个会话。这与锁超时仅取消语句的失败边界不同，连接池必须丢弃已经断开的连接。两种设置都不是跨多次尝试的应用总截止时间；事务开始前的排队，以及重试退避期间的耗时，仍应计入调用方预算。不要把一个数据库内计时器当成完整请求的时间保证。

快速验证

准备同一个 PostgreSQL 18 可丢弃数据库，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。实验使用默认的零值锁超时，且没有其他会提前干预的超时设置。下面的毫秒参数只用于快速复现，不是生产建议值。甲先建立独立模式和计数表：

CREATE SCHEMA timeout_demo;
CREATE TABLE timeout_demo.counter (id integer PRIMARY KEY,n integer);
INSERT INTO timeout_demo.counter VALUES (1,0);

甲在显式事务中把数字改成十，暂时不提交，也不回滚，以便继续持有目标行的锁：

BEGIN;
UPDATE timeout_demo.counter SET n=10 WHERE id=1;

乙开启事务，对同一行加一，并给取锁等待一百毫秒预算。为展示预期错误及后续事务状态，只在这一小段临时关闭遇错停止：

BEGIN;
SET LOCAL lock_timeout='100ms';
SET LOCAL statement_timeout='1s';
\set ON_ERROR_STOP off
UPDATE timeout_demo.counter SET n=n+1 WHERE id=1;
\echo lock_state :SQLSTATE
SELECT n FROM timeout_demo.counter WHERE id=1;
\echo transaction_state :SQLSTATE
\set ON_ERROR_STOP on
ROLLBACK;

下列结果是原有双会话练习的预期结果，本轮未重新执行并发会话。先得到 55P03，随后查询得到 25P02。前者取消乙的更新，并使这个显式事务进入失败状态；后者说明原事务不能继续正常执行。乙的回滚只清理自己的失败事务，不会释放甲的锁，也不会取消甲尚未提交的十。若忽略回滚，直接在原事务里重发更新，只会继续收到事务状态错误。

甲仍保持事务打开。乙重新开始，这次把整条语句预算设成五十毫秒，比取锁的一百毫秒更短：

BEGIN;
SET LOCAL lock_timeout='100ms';
SET LOCAL statement_timeout='50ms';
\set ON_ERROR_STOP off
UPDATE timeout_demo.counter SET n=n+1 WHERE id=1;
\echo statement_state :SQLSTATE
\set ON_ERROR_STOP on
ROLLBACK;

此时得到 57014，说明语句取消先发生。等待的依然是同一行，改变的只是哪个计时器先到期。错误码需要结合上下文解释：不等待的取锁请求也可能返回 55P03，其他查询取消也可能返回 57014。单看这些类别，既不能认定已经检测到死锁，也不能直接知道阻塞者属于哪个应用操作。

甲现在回滚，丢弃尚未提交的十并释放行锁：

ROLLBACK;

乙开启一个新的有界事务，再次更新，这次返回一并成功提交：

BEGIN;
SET LOCAL lock_timeout='100ms';
SET LOCAL statement_timeout='1s';
UPDATE timeout_demo.counter SET n=n+1 WHERE id=1 RETURNING n;
COMMIT;

结果是一，因为乙先前的失败尝试都没有提交增量，甲的十也已回滚。乙继续验证普通执行时间与取锁等待时间的区别：

BEGIN;
SET LOCAL lock_timeout='50ms';
SET LOCAL statement_timeout='1s';
SELECT pg_sleep(0.2);
\echo sleep_state :SQLSTATE
COMMIT;
SHOW lock_timeout;

睡眠持续二百毫秒，超过锁等待预算五十毫秒，但正常返回成功状态。没有等待锁，不能仅凭耗时长就触发锁超时。提交之后，显示的锁超时恢复为会话原来的零，因为局部设置只持续到当前事务结束。最后由甲核对数据仍为一，并清理实验：

SELECT n FROM timeout_demo.counter WHERE id=1;
DROP SCHEMA timeout_demo CASCADE;

恢复时不要扩大竞争

是否重试应由具体操作决定。锁超时后先回滚，只有剩余请求预算足够、并且重放符合业务语义时，才开始新事务。少量尝试、随机退避和总截止时间可以限制额外负载，却不能让永久占用的资源凭空可用。耗尽预算时应保留最终错误和尝试次数，而不是静默丢弃请求，或把它报告成成功。

真正的死锁是依赖关系形成了环，数据库检测后会返回死锁错误。锁超时也可能抢在死锁检测之前到期，所以“这次只看见超时”不能证明没有循环等待。应结合阻塞进程、事务持续时间与取锁顺序检查原因。让持锁事务早点结束，特别是移走其中等待用户输入或外部服务的环节，往往比整体调大超时更有效。生产参数必须参考正常锁持有时间和业务延迟预算，不能照抄这个实验的毫秒数。

来源

PostgreSQL 18 客户端连接默认值，锁等待、语句与空闲事务超时的作用范围，已核验 2026-10-15。
PostgreSQL 18 显式锁，锁冲突及死锁检测，已核验 2026-10-15。
PostgreSQL 错误码，锁不可用、查询取消和失败事务的 SQLSTATE 分类，已核验 2026-10-15。

fencing token 让过期的旧主节点失效

Tue, 30 Nov 2027 00:00:00 +0000

租约到期时，持有者可能只是暂停，并没有真正停止。旧进程恢复后，仍会发送迟到写入。存储服务需要一种方法拒绝已经被取代的所有权；围栏令牌提供有序的所有权世代编号，并随每次变更传递。保护来自资源侧实际检查，而不是锁服务仅仅发出了一个数字。理解这个执行位置，才能判断旧主是否真的被挡住。

光有锁还不够

客户端可以先检查租约，然后因垃圾回收暂停，等另一个客户端取得资源后才恢复。即使在发送前立即检查，也无法消除检查与使用之间的空隙。网络延迟同样可能让已经发送的请求很晚才到达。资源必须在操作真正到达时决定是否接受，不能只相信客户端记忆中的持有状态仍然有效。

租约超时是故障检测机制，不证明先前进程已经停止。旧进程的凭据可能仍能通过身份认证，但它的所有权已经过期。因此应区分身份认证、权限与所有权世代。围栏不替代访问控制，也不能允许恶意客户端随意声称一个极大的编号，把合法所有者永久挡在外面。合法编号的来源同样属于协议需要保证的边界。

把递增编号绑定到所有权

协调者在取得所有权时发出递增令牌。暂停的持有者仍只有旧编号，不能在没有重新取得所有权时，随便再申请一个新数字继续写。发号序列必须在故障后避免回退和复用；墙上时钟、分区节点各自维护的计数器，都不会自动具备这个契约。时间戳看起来更大，不等于它证明了有效的所有权交接。

被保护资源保存已接受的最大世代，拒绝更小编号，接受更大编号时推进高水位。比较和对应的数据变更必须在同一个原子、持久化边界内完成。如果先单独检查，再无条件写入，就重新制造了竞争窗口。复制资源还需要一致的执行边界，不能让每个副本独立比较、各自接受不同所有者，之后再声称全部操作已经被围栏保护。

相等编号需要单独定义策略

一个租约持有者通常会在同一世代里执行多次写入。如果拒绝所有等于高水位的编号，该持有者就只能成功写一次。常见的所有权世代规则拒绝较小值，相等值仍可按应用正常权限处理。每次操作都使用严格递增编号，是另一种协议，不能与每次取得所有权才发一枚令牌的机制混为一谈。

相等编号也不能说明某次操作是否重复。需要防止重试重复产生效果时，应使用操作标识、幂等更新或其他明确的顺序规则。围栏区分不同所有权世代，不会自动排列同一世代的全部操作，也不会自动去重，更不能单独保证业务效果恰好发生一次。把这些责任写清楚，可以避免用一个编号替代所有并发控制。

坏掉的样子

发出新令牌，不会立即通知所有被保护资源。在资源尚未见过新世代之前到达的旧写入，仍可能通过高水位检查。如果契约要求取得新所有权的一刻就立即撤销旧权限，需要在允许后续工作前，通过合适的协调步骤把新世代建立到资源侧。普通围栏不能描述成对全部在途请求的即时取消机制，测试应保留这个先后顺序边界。

计数器回退可能让新所有者拿到比旧持有者更小的编号。资源丢失持久化高水位，也可能重新接受旧世代。恢复流程必须同时保全发号序列与资源状态；只把一端恢复到旧备份，却不协调所有权，可能破坏原来的假设，即使两个组件都能正常启动。组件存活与协议仍安全，是不同判断。

缺失或格式错误的令牌不能悄悄绕过检查。检查每一条变更入口，包括维护任务和兼容客户端。不能执行令牌比较的文件服务或外部 API，需要另一种受支持的并发控制机制；仅在请求头中放一个数字，并不会保护实际副作用。比较必须位于真正拥有写入权的资源边界，而不是只存在于调用方日志中。

快速验证

把下面标准库 Python 示例保存为 fencing.py 后运行。它是顺序执行的内存模型，不是持久锁服务，也不是并发存储实现；没有外部服务器、系统时钟或真实凭据参与，所有状态都只存在于当前程序中。

class StaleFenceError(RuntimeError):
 pass

class FencingResource:
 """Sequential model: equal tokens permit more writes in the same epoch."""
 def __init__(self):
 self.last_seen = 0
 self.data = None

 def write(self, token, value):
 if type(token) is not int or token <= 0:
 raise StaleFenceError("missing or invalid fence token")
 if token < self.last_seen:
 raise StaleFenceError(f"stale token {token} < {self.last_seen}")
 self.last_seen = token
 self.data = value
 return True

class Issuer:
 """Test counter; a real issuer must bind durable epochs to ownership."""
 def __init__(self):
 self.counter = 0

 def acquire(self):
 self.counter += 1
 return self.counter

def refused(resource, token):
 before = (resource.last_seen, resource.data)
 try:
 resource.write(token, "must-not-land")
 except StaleFenceError as error:
 assert (resource.last_seen, resource.data) == before
 print("rejected:", error)
 else:
 raise AssertionError("invalid or stale write was accepted")

issuer = Issuer()
old_leader, new_leader = issuer.acquire(), issuer.acquire()
resource = FencingResource()
# Issuance alone has not informed this resource about epoch 2.
assert resource.write(old_leader, "arrived-before-new-epoch")
assert resource.write(new_leader, "from-new-leader")
refused(resource, old_leader)
assert resource.write(new_leader, "second-write-in-same-epoch")
assert resource.last_seen == 2
refused(resource, None)
refused(resource, "2")
refused(resource, True)
next_token = issuer.acquire()
assert resource.write(next_token, "newest")
refused(resource, new_leader)
assert (resource.last_seen, resource.data) == (3, "newest")
print("PASS: observed newer epochs fence older writes; equal epoch remains usable")

首次旧令牌写入成功，因为资源还没有观察到第二世代。第二世代写入后，第一世代被拒绝，已存数据和高水位都不改变。同一个第二世代随后还能再写，说明一位所有者可以合法进行多次操作。缺失值、字符串和布尔值被拒绝；第三世代到来后，第二世代也成为旧值，不能继续修改资源。

最后的 PASS 只确认这些比较分支，不验证持久化、原子事务、协调者授权、分区恢复或网络时序。把模型转为集成测试时，必须保留这些限制，并让生产资源在真正发生副作用的位置执行相同所有权边界。仅让演示断言通过，不能宣布一个尚未接受并发与恢复测试的分布式系统已经安全。

来源

Redis 分布式锁，围栏建议与分布式锁限制，已核验 2026-10-15。
如何做分布式锁，取得所有权时递增的令牌与资源侧拒绝旧世代，已核验 2026-10-15。

建议锁寿命属于连接或事务

Wed, 24 Nov 2027 00:00:00 +0000

建议锁让应用使用一个标识来协调工作，不要求这个标识对应数据库里某一行。比如，多名工作者可以约定，同一时间只能有一个连接刷新某份报表。PostgreSQL 负责管理锁的持有与竞争，应用则负责定义标识的业务含义，以及哪些操作必须先拿锁才能执行。这个分工决定了它能提供的保障，也决定了绕过协议时会发生什么。

坏掉的样子

建议锁的键只能是一个大整数，或者两个普通整数，没有接受文本名字的函数重载。这两种键空间彼此独立。如果应用通过哈希把名称映射为数字，必须明确一致的编码规则，也要考虑碰撞；同一资源被不同算法映射到不同数字，同样会破坏协调。直接维护有文档的整数命名空间，通常比隐藏在各个调用方里的临时哈希规则更容易核对。

建议锁是参与者共同遵守的协议。忽略它的连接，仍然可以更新所谓受保护的表行；它不能代替唯一约束、事务或权限检查。会话锁在回滚后仍然保留，直到对应次数的解锁完成，或服务器结束该会话。事务锁则随事务结束释放。如果处于自动提交模式，一条语句取得的事务锁，在后续语句开始之前就已经释放，无法保护接下来才执行的工作。

快速验证

本轮没有重跑原样保留的双会话示例：单用户后端不能复现会话间竞争。以下结果保留为预期，不是新的并发验证。

准备同一个 PostgreSQL 18 可丢弃数据库，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。为本实验预留下面的整数键，不要与已有业务约定混用。按照块的顺序切换终端。甲先创建计数器：

CREATE SCHEMA advisory_demo;
CREATE TABLE advisory_demo.counter (id integer PRIMARY KEY,n integer);
INSERT INTO advisory_demo.counter VALUES (1,0);

甲传入显式文本类型的键，预期返回 42883，即不存在匹配的函数。故意报错这一段结束后恢复遇错停止设置：

\set ON_ERROR_STOP off
SELECT pg_advisory_lock('job-name'::text);
\echo text_key_state :SQLSTATE
\set ON_ERROR_STOP on

甲在事务里把同一把会话锁取两次，然后回滚。注意函数名使用的是会话级形式：

BEGIN;
SELECT pg_advisory_lock(8610,2);
SELECT pg_advisory_lock(8610,2);
ROLLBACK;

乙尝试非阻塞取锁，接着故意不遵守建议锁协议，直接更新计数器：

SELECT pg_try_advisory_lock(8610,2);
UPDATE advisory_demo.counter SET n=n+1 WHERE id=1 RETURNING n;

取锁返回假，更新却返回一。两个结果分别证明：甲的回滚没有释放会话锁；建议锁也没有自动阻挡普通表写入。甲现在解锁一次：

SELECT pg_advisory_unlock(8610,2);

虽然解锁返回真，乙仍然无法获得同一把锁：

SELECT pg_try_advisory_lock(8610,2);

甲还需要解除第二次获取：

SELECT pg_advisory_unlock(8610,2);

这时乙能够成功取锁，并明确释放自己刚获得的那一次持有：

SELECT pg_try_advisory_lock(8610,2);
SELECT pg_advisory_unlock(8610,2);

两个调用都返回真。同一会话重复成功取锁会累加持有次数，所以一次解锁成功，并不能证明该会话已经完全放弃资源。下一步，甲对另一个键使用事务级函数，并保持显式事务打开：

BEGIN;
SELECT pg_advisory_xact_lock(8610,3);

乙的非阻塞事务锁请求返回假，说明甲仍拥有该键：

SELECT pg_try_advisory_xact_lock(8610,3);

甲回滚，结束事务级持有：

ROLLBACK;

乙在自动提交模式下重新申请，这次返回真：

SELECT pg_try_advisory_xact_lock(8610,3);

紧接着，甲也在自动提交模式下申请相同的事务锁，仍返回真：

SELECT pg_try_advisory_xact_lock(8610,3);

两个真是先后成功，不是同时拥有同一把互斥锁。每条语句的隐式事务结束时，就已释放当次锁。此刻双方都不能认为自己还保护着未来的临界区。最后由甲核对计数值仍是一，并删除实验模式：

SELECT n FROM advisory_demo.counter WHERE id=1;
DROP SCHEMA advisory_demo CASCADE;

非阻塞取锁失败不会增加需要释放的持有次数。只有成功获取，才会成为当前会话或事务实际拥有的锁。

让持有寿命覆盖完整操作

如果被保护的数据库工作可以放在一个事务中，应显式开启事务、获取事务锁，再完成读取、判断和写入，最后结束事务。非阻塞取锁返回假时，意味着调用方没有取得所有权；此时应跳过或重新安排任务，不能无视返回值继续执行受保护工作。阻塞版本可能等待，因此取锁预算和重试策略也必须纳入这个业务操作的总时限。

只有确实需要跨越多次事务的持有周期时，才选择会话锁，而且获取、工作和释放必须使用同一条物理数据库连接。如果持锁后把连接还给池，后台会话可能继续持锁，却开始服务不相关的请求。事务池化尤其不能支持“下次请求仍回到原来那个持锁会话”的假设。这里要核对真实连接寿命，而不是仅看应用对象是否还是同一个名字。

服务器结束会话时会自动清理会话锁，不存在会话已经终止但锁永久残留的正常语义。不过，网络连接丢失的检测可能有延迟，不能假定客户端消失后其他工作者立即获得锁。锁也不记录任务是否已经完成。后续工作者取得所有权后，仍应检查已提交状态，判断是否需要执行，以及重复执行是否符合任务语义，不能把“我现在拿到了锁”误当成“此前无人完成过”。

来源

PostgreSQL 18 建议锁函数，允许的键类型及阻塞、非阻塞接口，已核验 2026-10-15。
PostgreSQL 18 显式锁，建议锁持有、重复获取和事务语义，已核验 2026-10-15。

死锁：两个写者在互相等待

Tue, 11 Aug 2026 00:00:00 +0000

死锁需要不兼容的等待关系形成一个环。一个事务持有行锁、另一个事务等待时，持锁者仍可能正常结束并放锁；双方各自握着对方必须获得的资源时，就无法沿当前路径完成。PostgreSQL 会检测这种循环，中止其中一个事务，让另一个继续。应用需要区分服务器明确拒绝事务与普通的慢等待，而不是把所有停顿都叫作死锁。

坏掉的样子

即使没有显式锁语句，更新行也会获取锁。因此，两段看起来简单的更新，如果以相反顺序访问两行，就可能互相等待。参与者更多、包含外键检查、触发器、建议锁或锁模式升级时，依赖环会更难看见。给某一段行编号排序，只能解决这部分访问顺序，不能据此证明整个业务路径再也没有死锁。

数据库检测到死锁时返回 40P01。应用不能依赖“后开始者必输”或“工作量少的一方会被中止”之类规则。锁等待超时、语句超时也可能先于死锁检测触发，返回另一种错误。因此必须查看实际错误码和服务器诊断，再判断发生了什么。没有看到死锁码，并不等于没有形成过循环；重试了一次，也不代表原来的取锁顺序已经修好。

快速验证

准备同一个 PostgreSQL 18 可丢弃数据库，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。甲创建两行数据，并显示死锁检测等待参数：

CREATE SCHEMA deadlock_demo;
CREATE TABLE deadlock_demo.items (id integer PRIMARY KEY,n integer);
INSERT INTO deadlock_demo.items VALUES (1,0),(2,0);
SHOW deadlock_timeout;

本次环境显示一秒。下面给语句十秒预算，让检测有时间发生，并确保没有更短的锁超时抢先干预。如果你的检测间隔更长，应相应调整实验预算。甲记录自己要增加的十，并先更新第一行，暂不提交：

\set delta 10
SET statement_timeout='10s';
BEGIN;
UPDATE deadlock_demo.items SET n=n+:delta WHERE id=1;

乙记录自己要增加的一百，先更新第二行，也保持事务打开：

\set delta 100
SET statement_timeout='10s';
BEGIN;
UPDATE deadlock_demo.items SET n=n+:delta WHERE id=2;

甲继续更新第二行，此时会等待乙的锁。提交这个块后，应立即切换到乙终端，不要等甲这条更新结束：

\set ON_ERROR_STOP off
UPDATE deadlock_demo.items SET n=n+:delta WHERE id=2;
\echo second_result :SQLSTATE
\set ON_ERROR_STOP on

甲等待期间，乙申请更新第一行：

\set ON_ERROR_STOP off
UPDATE deadlock_demo.items SET n=n+:delta WHERE id=1;
\echo second_result :SQLSTATE
\set ON_ERROR_STOP on

现在循环等待已经形成。一个终端输出死锁错误，另一个最终输出成功状态，甲或乙都可能成为失败者。演示中暂时允许预期错误继续显示，只是为了看清两种结果，不会决定数据库选谁中止。先在收到 40P01 的失败终端执行回滚，结束已经失败的事务：

ROLLBACK;

再在得到成功状态的终端提交完整操作：

COMMIT;

之后任选一个终端读取两行：

SELECT id,n FROM deadlock_demo.items ORDER BY id;

如果甲获胜，两行都是十；如果乙获胜，两行都是一百。不应出现一行十、一行一百的混合结果。失败者第一条已经成功执行的更新，也随着事务中止被撤销；不能把“第一条语句曾返回成功”记成业务操作已经提交了一半。这里的结果验证的是完整事务的原子性，而不只是两条连接最终都恢复响应。

现在回到失败者原来的终端，重试整个操作。该终端保存的增量变量仍然代表它原本要做的工作。先按编号顺序锁定两行，再执行更新并提交：

BEGIN;
SELECT id FROM deadlock_demo.items ORDER BY id FOR UPDATE;
UPDATE deadlock_demo.items SET n=n+:delta;
COMMIT;

锁定查询依次返回一和二。此时胜者已经提交，所以重试能够完成。最后任选终端核对两笔增量恰好各保留一次，并清理实验：

SELECT id,n FROM deadlock_demo.items ORDER BY id;
DO $$ BEGIN
 IF (SELECT array_agg(n ORDER BY id) FROM deadlock_demo.items) IS DISTINCT FROM ARRAY[110,110] THEN
 RAISE EXCEPTION 'deadlock recovery lost or duplicated work';
 END IF;
END $$;
DROP SCHEMA deadlock_demo CASCADE;

两行都必须是一百一十。断言不仅检查有没有错误，还能发现少做一次或重复一次的恢复问题。整个实验应保留原来的两个会话；如果临时开第三个终端执行重试，它没有失败者保留的客户端变量，也就不知道该恢复十还是一百。恢复对象由失败的完整操作决定，不能随意把成功者也重放一遍。

沿完整路径避免重复发生

当所有参与者都遵守同样的顺序，且行标识保持稳定时，固定顺序可以消除这里展示的双行循环。真实系统需要把这套顺序扩展到相关的其他资源，并有意识地选择所需锁模式。触发器和约束检查可能隐式访问另一张表；如果只审查表面上的两条更新，局部有序仍然无法排除其他路径引入的循环。

缩短事务、避免持锁等待用户或远程服务，可以减少占用窗口。收到服务器明确的死锁拒绝后，应回滚，再连同读取和业务判断一起重试。高竞争时要有次数、时间预算与随机退避，预算用完则上报最终错误。频繁死锁仍然需要检查访问顺序和负载分布，因为检测和重试都会消耗时间，有限重试更不承诺一定成功。这个实验展示了可核对的恢复结果，不是对任意工作负载都免于死锁的保证。

来源

PostgreSQL 18 显式锁，死锁循环、不可依赖的受害者选择及取锁顺序，已核验 2026-09-10。
PostgreSQL 18 序列化失败处理，并发失败后重试完整事务，已核验 2026-09-10。

锁 · XB 现场笔记

InnoDB 死锁会回滚整个受害事务

坏掉的样子

快速验证

减少等待环，但不假定它们消失

来源

事务拿锁时别的请求会礼貌等待

坏掉的样子

快速验证

恢复时不要扩大竞争

来源

fencing token 让过期的旧主节点失效

光有锁还不够

把递增编号绑定到所有权

相等编号需要单独定义策略

坏掉的样子

快速验证

延伸阅读

来源

建议锁寿命属于连接或事务

坏掉的样子

快速验证

让持有寿命覆盖完整操作

来源

死锁：两个写者在互相等待

坏掉的样子

快速验证

沿完整路径避免重复发生

来源