PostgreSQL的锁机制常常让初学者感到困惑：明明只是一个普通的SELECT查询，为什么会导致后来的ALTER TABLE语句一直卡住？而ALTER TABLE一旦排队，又为什么后面所有的读写请求都被堵死了？这种连锁阻塞的背后，是PostgreSQL严格的锁队列机制在起作用。理解表级锁的工作原理，是解决并发访问阻塞问题的第一步。
一、PostgreSQL表级锁的八种模式与兼容性矩阵
PostgreSQL在表级别定义了八种锁模式，从弱到强分别是ACCESS SHARE、ROW SHARE、ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE和ACCESS EXCLUSIVE。每种锁模式的提出都有明确的用途：普通的SELECT语句会自动获取ACCESS SHARE锁，INSERT、UPDATE、DELETE会获取ROW EXCLUSIVE锁，而CREATE INDEX（不带CONCURRENTLY）需要SHARE锁，ALTER TABLE、DROP TABLE、TRUNCATE则需要最强级别的ACCESS EXCLUSIVE锁。
理解阻塞的关键在于锁的兼容性矩阵。ACCESS EXCLUSIVE与所有锁模式都冲突，EXCLUSIVE与除ACCESS SHARE之外的所有模式冲突。也就是说，一旦DDL语句进入等待队列，任何后续的读写操作都无法越过它先执行，这就是所谓的“锁队列插队禁止”规则。PostgreSQL的锁队列是严格FIFO的，即使后来的请求与队列前面的锁并不冲突，也可能被前面的等待者挡住。
举个典型场景：线上有一个长跑的报表查询持有ACCESS SHARE锁，此时执行ALTER TABLE ADD COLUMN需要ACCESS EXCLUSIVE锁，只能等待；紧接着的业务读写请求又排在ALTER TABLE后面，即使它们本可以与报表查询共存，也只能一起等待。这就是“一个慢查询拖垮整个表”的经典案例。
二、为什么长事务是阻塞的罪魁祸首
在PostgreSQL的MVCC机制下，SELECT查询本身获取的ACCESS SHARE锁非常轻量，几乎不会与其他读操作冲突。真正的问题在于事务的持续时间。一个事务只要未提交，它持有的所有表锁都不会释放。如果应用代码中存在“先查询，再做耗时外部调用，最后提交”的写法，那么这个事务可能持有锁长达数分钟甚至数小时。
更隐蔽的是空闲事务。有些连接池配置不当，事务被遗忘在idle in transaction状态，这种连接持有的锁会一直存在，直到事务超时或被强制终止。可以通过下面的查询快速定位这类危险连接：
SELECT pid, state, now() - xact_start AS xact_age,
now() - state_change AS idle_time, query
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND now() - state_change > interval '5 minutes';
找到之后，可以使用SELECT pg_terminate_backend(pid);终止这些连接，释放它们持有的锁资源。但要根治问题，还需要从应用层入手：将外部HTTP调用、消息发送等耗时操作移到事务之外，尽量缩短事务的生存期。
三、避免阻塞的实用手段
第一种手段是设置lock_timeout。默认情况下，DDL语句会无限期等待锁，这在生产环境中非常危险。为DDL会话显式设置锁超时，可以让它快速失败重试，而不是长期占着队列阻塞后续请求：
-- 设置锁等待超时为3秒，语句级生效 SET lock_timeout = '3s'; ALTER TABLE orders ADD COLUMN remark text; RESET lock_timeout;
注意lock_timeout要与其他会话的statement_timeout区分开。前者控制的是“等待锁的时间”，后者控制的是“语句执行的总时间”。在执行DDL前设置lock_timeout，即使失败也不会长时间堵塞队列，配合脚本自动重试可以实现在业务低峰期“见缝插针”地完成DDL。
第二种手段是使用非阻塞的DDL替代方案。例如创建索引时使用CREATE INDEX CONCURRENTLY，它只短暂请求SHARE UPDATE EXCLUSIVE锁，不会阻塞读写。添加带默认值的列在PostgreSQL 11之后也是元数据级操作，不再重写整表。对于复杂的表结构变更，可以考虑使用pg_repack这类扩展工具，它能在几乎不阻塞业务的情况下完成表重建和清理膨胀。
第三种手段是主动监控与预防。通过pg_locks视图可以实时观察锁的持有与等待关系：
SELECT blocked.pid AS blocked_pid, blocked.query AS blocked_query,
blocking.pid AS blocking_pid, blocking.query AS blocking_query
FROM pg_locks bl
JOIN pg_stat_activity blocked ON bl.pid = blocked.pid
JOIN pg_locks ul ON bl.locktype = ul.locktype
AND bl.relation IS NOT DISTINCT FROM ul.relation
JOIN pg_stat_activity blocking ON ul.pid = blocking.pid
WHERE NOT bl.granted AND ul.granted;
建议将这类查询做成定时任务，一旦发现锁等待链超过一定长度就报警。同时，为idle_in_transaction_session_timeout设置合理值，从参数层面杜绝遗忘事务长期持锁的可能。
四、从架构层面减少表锁竞争
除了语句级的优化，架构设计同样重要。首先，将DDL操作纳入标准的发布流程，避免在业务高峰执行表结构变更，尽量安排在维护窗口或流量低谷期。其次，控制单表事务的规模，大批量UPDATE或DELETE应当分批执行，每批控制在几千到几万行，这样既能减少锁持有时间，也能降低主从复制的延迟。
对于读写分离的架构，要注意锁信息不会跨实例传播，主库上的锁等待不会直接影响只读副本，但逻辑复制场景下主库DDL卡住会导致复制槽积压，进而撑爆磁盘。因此在流复制或逻辑复制的环境中，DDL的阻塞影响会被放大，更需要严格的事务纪律。
最后，合理配置连接池也很关键。PgBouncer在transaction pooling模式下，事务结束后连接会被归还重用，天然避免了应用层长事务持锁的问题。但要注意prepared statement在transaction模式下的兼容性，避免因语句缓存失效引发新的故障。
总结来看，PostgreSQL表级锁本身设计得相当精细，绝大多数阻塞问题源于不当的使用方式：过长的DDL等待、被遗忘的空闲事务、高峰期的结构变更。只要掌握锁兼容性矩阵，善用lock_timeout与CONCURRENTLY选项，建立完善的锁监控体系，就能在保证数据一致性的同时，让并发访问流畅运转。
PostgreSQL表级锁并发控制MVCC修改时间：2026-09-01 08:37:03