PostgreSQL函数为何发生死锁？关联元组死锁问题问询

这问题我碰到过好几次——按说只要严格固定元组的访问/加锁顺序，死锁应该完全可以避免，但实际还是出了状况，大概率是你没注意到的「隐性变量」在搞鬼。我来帮你拆解可能的原因和排查方向：

1. 你以为的「固定顺序」，实际执行计划根本没遵守 #

很多人会犯一个错：逻辑上觉得自己是按Album→Photo的顺序处理元组，但没在FOR UPDATE查询里显式加ORDER BY Album, Photo。

PostgreSQL的查询优化器会根据索引、数据分布等选择最高效的执行路径，比如如果你的查询用了Photo列的索引，它可能会先按Photo的顺序扫描行，这时候加锁的顺序就彻底乱了！哪怕你后续的UPDATE是按顺序来的，FOR UPDATE阶段的锁顺序不一致，照样会触发死锁。

解决办法：给FOR UPDATE的查询强制加上ORDER BY Album, Photo，确保PostgreSQL严格按这个顺序获取并锁定元组。

2. 触发器/约束带来的「隐式锁操作」 #

如果你的关联表有外键约束、触发器（比如AFTER UPDATE/BEFORE UPDATE触发器），这些隐式操作可能在你不知情的情况下改变了锁的顺序。

举个例子：假设关联表有外键指向Photo表，当你执行UPDATE时，PostgreSQL会先去锁定Photo表对应的行（验证外键完整性）；而如果另一个事务先锁定了Album表的行，再去碰Photo，就会形成交叉等待的死锁。

排查方向：

• 检查关联表上的所有触发器，看它们有没有操作其他表的逻辑；
• 查看外键约束的级联操作（比如ON UPDATE CASCADE），这些都会带来额外的锁；
• 用pg_locks视图实时观察死锁发生时的锁持有情况，看有没有意料之外的锁类型。

3. 函数或事务的「分支逻辑破坏顺序」 #

仔细检查那个引发死锁的函数，有没有分支判断逻辑？比如在某些条件下，会先处理Photo对应的元组，再处理Album的？或者这个函数被嵌套在更大的事务里，调用方在执行函数之前已经操作了Photo表的行？

哪怕99%的路径都是按Album→Photo来的，只要有1%的路径反过来，死锁就必然会发生。

解决办法：梳理所有代码路径（包括调用该函数的上层逻辑），确保任何情况下，锁的获取顺序都是完全一致的——先Album相关元组，再Photo相关元组，没有例外。

4. 范围查询带来的「间隙锁冲突」 #

如果你的FOR UPDATE用了范围条件（比如WHERE Album >= 100），在PostgreSQL的**可重复读（REPEATABLE READ）**隔离级别下，会自动加间隙锁（Gap Lock）来防止幻读。这种情况下，不同事务可能在相邻的间隙上形成交叉锁等待。

比如：

• 事务A锁定了Album=100的行及其后续间隙；
• 事务B锁定了Album=99的行及其后续间隙；
• 两者互相等待对方释放间隙锁，触发死锁。

解决方向：

• 如果业务允许，把隔离级别降到读提交（READ COMMITTED），这个级别下不会加间隙锁；
• 调整查询条件，尽量用精确匹配代替范围查询；
• 业务场景允许的话，使用FOR UPDATE SKIP LOCKED跳过已被锁定的行，避免等待。

最关键的排查步骤：看死锁日志 #

打开PostgreSQL的log_lock_waits和log_statement参数，死锁发生时，日志里会详细记录每个事务持有的锁、等待的锁，以及执行的SQL语句。这是定位问题最直接的依据——比如你能看到是不是某个隐式操作加了额外的锁，或者某个查询的锁顺序确实和你想的不一样。

内容的提问来源于stack exchange，提问作者MrSuaveh