PostgreSQL的锁机制远比很多人想象的要复杂，表级锁和行级锁只是最表层的分类。在高并发写入场景中，真正决定系统吞吐量和响应时间的是加锁顺序。一条看似普通的UPDATE语句，在PostgreSQL内部可能会按特定顺序获取多个锁，如果不同事务之间对相同资源的加锁先后不一致，轻则出现锁等待，重则触发死锁回滚。本文将从锁类型、死锁形成、执行计划中的锁顺序以及监控优化几个方面，系统解析加锁顺序对性能的影响。
一、PostgreSQL的锁类型与冲突矩阵
PostgreSQL将锁分为表级锁和行级锁两大类。表级锁有八种模式，从弱到强依次是AccessShareLock、RowShareLock、RowExclusiveLock、ShareUpdateExclusiveLock、ShareLock、ShareRowExclusiveLock、ExclusiveLock和AccessExclusiveLock。每种模式允许的并发操作不同，例如AccessShareLock只与AccessExclusiveLock冲突，而RowExclusiveLock则与ShareLock、ShareRowExclusiveLock、ExclusiveLock和AccessExclusiveLock都冲突。行级锁则包括FOR UPDATE、FOR NO KEY UPDATE、FOR SHARE和FOR KEY SHARE四种，它们的冲突关系更加细粒度。
理解冲突矩阵是分析锁顺序的前提。PostgreSQL在多个后端进程同时请求同一个对象上的锁时，会按照请求时间排队，并允许不冲突的请求同时持有。如果某个请求与队列中已有的锁模式冲突，它必须等待。这种等待并不是无限的，由lock_timeout和deadlock_timeout两个参数控制。deadlock_timeout默认1秒，PostgreSQL在这段时间内检测锁等待是否成环，如果成环则选择一个事务回滚。因此，加锁顺序不当造成的交叉等待往往在1秒后就会表现为死锁错误。
实际中，很多性能问题并不是单个语句执行慢，而是锁等待时间占用了连接数。比如一个事务先锁住了订单表，再去更新库存表，另一个事务先锁库存再更新订单，两个事务都只完成了一半操作，互不相让。PostgreSQL通过死锁检测会发现这种环状等待，但回滚其中一个事务会导致该连接之前所有修改被撤销，浪费CPU和磁盘I/O。更糟的是，如果死锁频繁发生，应用层可能会不断重试，进一步加剧负载。
二、加锁顺序如何形成死锁
用一个经典场景说明。假设有两张表：accounts账户表和orders订单表，一个业务流程需要从账户扣款并生成订单。事务A先执行UPDATE accounts SET balance = balance - 100 WHERE id = 1，然后再执行UPDATE orders SET status = 'paid' WHERE account_id = 1；事务B刚好相反，先更新orders表，再更新accounts表。事务A首先获得accounts表中id=1行的行级排他锁，事务B获得orders表中account_id=1行的锁。随后事务A尝试更新orders时，发现这行已经被事务B锁定，于是进入等待；而事务B尝试更新accounts时，发现被事务A锁定，也进入等待。两个事务互相等待对方释放锁，形成死锁。
PostgreSQL的死锁检测器会在deadlock_timeout后扫描全局等待图，发现这个环后，选择一个事务作为牺牲品并报出ERROR: deadlock detected。通常选择回滚代价较小的事务，但默认情况下PostgreSQL并不比较代价，而是随机选择。如果应用没有合理重试机制，用户会看到错误；如果重试过多，又会放大负载。
-- 事务A BEGIN; UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- 此时已持有accounts表中id=1的行级排他锁 UPDATE orders SET status = 'paid' WHERE account_id = 1; -- 尝试获取orders表中account_id=1的行级锁，会被事务B阻塞 COMMIT; -- 事务B（并发执行） BEGIN; UPDATE orders SET status = 'pending' WHERE account_id = 1; -- 持有orders表中account_id=1的行级排他锁 UPDATE accounts SET balance = balance - 50 WHERE id = 1; -- 尝试获取accounts表中id=1的行级锁，被事务A阻塞 COMMIT;
这个例子说明锁顺序并非数据库自动保证一致，而是由应用代码的SQL顺序决定。如果所有事务都遵循相同的更新顺序，比如先更新accounts再更新orders，就永远不会出现交叉等待。反之，只要存在两个不同的代码路径以相反顺序更新同一组资源，死锁风险就会存在。即使业务逻辑看似不同，只要涉及的资源重叠就可能触发。
三、语句内部加锁顺序的来源
除了应用代码中的SQL顺序，PostgreSQL在单条SQL语句内部也有固定的锁获取顺序。例如UPDATE语句首先会在目标表上获取RowExclusiveLock表级锁，然后通过索引或顺序扫描定位到符合条件的行，逐行获取行级排他锁。如果该语句涉及外键约束，PostgreSQL还会在引用表上获取AccessShareLock或RowShareLock，用于确保外键关系在更新期间不被破坏。这些内部锁的获取顺序通常由查询计划决定，但总体上遵循先表级锁再行级锁、先主表再外键引用表的顺序。
不同的SQL写法可能导致不同的锁顺序。比如使用INSERT ... ON CONFLICT DO UPDATE会在插入前先获取意向锁并尝试定位冲突行，而MERGE语句则可能同时涉及源表和目标表的锁。如果在一个事务中先执行一条JOIN多表的UPDATE，PostgreSQL会先锁定FROM列表中靠前的表，再逐步锁定后续表。这一点可以从执行计划中的LockRows节点和EXPLAIN (FORMAT JSON)输出看到锁信息。了解这些内部顺序有助于我们预判冲突。
使用EXPLAIN分析加锁顺序需要开启auto_explain或者查看pg_locks在语句执行过程中的变化。但更直接的方法是控制事务中多条SQL的顺序。对于复杂业务，可以显式使用SELECT ... FOR UPDATE提前锁定所有需要修改的行，并按照固定顺序编写语句，这样即使多条SQL连续执行，锁的获取顺序也是可控的。
四、优化加锁顺序的实用策略
第一条策略是固定全局资源锁定顺序。在涉及多表或多行更新的业务中，团队应当约定统一的更新顺序，比如先更新主表再更新明细表，或者先锁定ID较小的记录再锁定ID较大的记录。对于账户和订单这种依赖关系，可以先处理accounts再处理orders，所有相关代码都遵守这个顺序。如果无法确定业务顺序，也可以按照表名的字母顺序或主键排序来统一。
第二条策略是使用SELECT ... FOR UPDATE提前锁定所有需要的行。在事务开头一次性锁定所有资源，可以减少后续等待。例如：
BEGIN; SELECT * FROM accounts WHERE id IN (1, 2) ORDER BY id FOR UPDATE; SELECT * FROM orders WHERE account_id IN (1, 2) ORDER BY account_id FOR UPDATE; -- 后续的UPDATE不会因为锁顺序冲突而等待 UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE orders SET status = 'paid' WHERE account_id = 1; COMMIT;
上述代码中，通过ORDER BY id和ORDER BY account_id确保所有事务都以相同的顺序锁定行，有效避免交叉等待。FOR UPDATE会获取行级排他锁，并跳过MVCC快照的限制，确保读取到的行其他事务无法修改。需要注意的是，FOR UPDATE会一直持有锁直到事务结束，所以必须在事务中尽快完成业务逻辑并提交，否则会扩大锁持有时间。
第三条策略是控制锁等待时间。PostgreSQL提供了lock_timeout参数，可以限制单个锁等待的最长时间。比如在会话中执行SET lock_timeout = '2s'，当锁等待超过2秒时会直接报错而不是无限等待。这可以避免连接被长时间阻塞，让应用快速失败并重试。同时可以配合NOWAIT选项，SELECT ... FOR UPDATE NOWAIT表示如果行已被锁定立即返回错误；SKIP LOCKED选项则跳过已锁定的行，适用于任务队列等场景。
第四条策略是缩短事务长度和锁的持有时间。所有行级锁在事务提交或回滚时才释放，所以事务中不要执行无关的慢查询、外部API调用或长时间计算。把一致性要求不高的读操作放到事务外，将先读后写改为直接条件UPDATE，避免先SELECT再UPDATE拉长锁持有窗口。
五、通过系统视图监控锁顺序问题
当怀疑系统中存在锁等待时，可以查询pg_locks视图和pg_stat_activity视图。pg_locks记录当前所有锁的持有和等待关系，pg_stat_activity显示后端进程正在执行的SQL。通过关联这两个视图，可以找出哪个进程在等待哪个锁，以及持锁进程的SQL。下面是一个常用的查询语句：
SELECT blocked.pid AS blocked_pid, blocked.usename AS blocked_user, blocked.query AS blocked_query, blocking.pid AS blocking_pid, blocking.query AS blocking_query FROM pg_stat_activity blocked JOIN pg_locks blocked_locks ON blocked.pid = blocked_locks.pid JOIN pg_locks blocking_locks ON blocked_locks.locktype = blocking_locks.locktype AND blocked_locks.database IS NOT DISTINCT FROM blocking_locks.database AND blocked_locks.relation IS NOT DISTINCT FROM blocking_locks.relation AND blocked_locks.page IS NOT DISTINCT FROM blocking_locks.page AND blocked_locks.tuple IS NOT DISTINCT FROM blocking_locks.tuple AND blocked_locks.virtualxid IS NOT DISTINCT FROM blocking_locks.virtualxid AND blocked_locks.transactionid IS NOT DISTINCT FROM blocking_locks.transactionid AND blocked_locks.classid IS NOT DISTINCT FROM blocking_locks.classid AND blocked_locks.objid IS NOT DISTINCT FROM blocking_locks.objid AND blocked_locks.objsubid IS NOT DISTINCT FROM blocking_locks.objsubid AND blocked_locks.pid != blocking_locks.pid JOIN pg_stat_activity blocking ON blocking.pid = blocking_locks.pid WHERE NOT blocked_locks.granted;
该查询通过比较锁对象判断等待关系，可以快速定位阻塞链。在PostgreSQL 14及以上版本中，可以直接使用pg_blocking_pids函数获取阻塞某个进程的所有PID。不过要注意，死锁检测器只会报告已经形成的环，对于尚未成环但长时间等待的锁，需要结合log_lock_waits参数和锁等待日志进行排查。
此外，可以开启log_lock_waits = on，PostgreSQL会在锁等待超过deadlock_timeout时记录日志，格式包含等待的锁类型和被等待的PID。定期分析这些日志，能够发现哪些SQL经常参与锁等待，从而反推代码中的加锁顺序问题。pg_stat_statements扩展也能提供语句级别的锁等待统计，但需要额外配置。
PostgreSQL锁顺序数据库死锁事务并发性能修改时间：2026-09-27 17:42:13