PostgreSQL LOCK（锁）（千字长文）

💡一则或许对你有用的小广告

欢迎加入小哈的星球 ，你将获得：专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

• 新项目:《从零手撸：仿小红书（微服务架构）》 正在持续爆肝中，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...，点击查看项目介绍 ;
• 《从零手撸：前后端分离博客项目（全栈开发）》 2 期已完结，演示链接： http://116.62.199.48/ ;

截止目前， 星球 内专栏累计输出 82w+ 字，讲解图 3441+ 张，还在持续爆肝中.. 后续还会上新更多项目，目标是将 Java 领域典型的项目都整一波，如秒杀系统, 在线商城, IM 即时通讯，权限管理，Spring Cloud Alibaba 微服务等等，已有 2900+ 小伙伴加入学习 ，欢迎点击围观

在数据库管理系统中，PostgreSQL LOCK（锁） 是保障并发操作安全性和一致性的核心机制。随着应用程序复杂度的提升，多用户同时访问数据库资源的情况越来越普遍。锁机制通过协调事务之间的资源访问冲突，避免了数据不一致、脏读或丢失更新等问题。然而，锁的不当使用也可能引发性能瓶颈甚至死锁，因此掌握其原理和最佳实践对开发者至关重要。本文将从基础概念、锁类型、冲突规则、案例分析等方面展开，帮助读者系统性理解 PostgreSQL 的锁机制。

什么是 PostgreSQL 锁？

锁（Lock）可以理解为一种“资源占用标识符”，它通过限制资源的访问权限，确保同一时间只有特定事务能修改数据。例如，当一个事务正在更新某条记录时，其他事务需要等待该事务提交或回滚后才能执行修改操作。这种机制如同“停车场”的管理规则：当一辆车占用停车位时，其他车辆必须等待空位释放才能进入。

在 PostgreSQL 中，锁分为多种类型，每种类型对应不同的资源粒度（如行、页、表）和持有方式（如共享锁、排他锁）。锁的类型和策略将直接影响数据库的并发性能和数据一致性。

PostgreSQL 锁的核心概念与分类

1. 锁的资源粒度

锁的粒度决定了锁定范围的大小，粒度越细，系统可同时处理的并发操作越多，但管理开销也越大。PostgreSQL 支持以下粒度：

• 表级锁（Table-Level Lock）：锁定整张表，适用于全表扫描或批量操作。
• 页级锁（Page-Level Lock）：锁定物理存储中的一个数据页（默认 8KB），用于优化相邻行的并发访问。
• 行级锁（Row-Level Lock）：锁定单条记录，提供最高并发性，但需额外内存和管理成本。

2. 锁的类型

PostgreSQL 的锁类型主要分为 共享锁（Share Lock） 和 排他锁（Exclusive Lock），它们的组合规则如下：
| 锁类型 | 兼容性规则 |
|-----------------|--------------------------------------------------------------------------|
| 共享锁（S） | 多个事务可同时持有同一资源的共享锁，但需等待排他锁的释放。 |
| 排他锁（X） | 排他锁独占资源，与其他所有锁（包括共享锁）互斥。 |

3. 锁的自动与显式控制

PostgreSQL 默认会根据 SQL 语句自动分配锁。例如，SELECT FOR UPDATE 会为选中的行添加排他锁，而 VACUUM 命令会持有表级共享锁。开发者也可通过 LOCK TABLE 显式指定锁类型和范围，例如：

BEGIN;  
LOCK TABLE orders IN SHARE MODE; -- 显式申请表级共享锁  
SELECT * FROM orders;  
COMMIT;  

锁的典型应用场景与案例

场景 1：防止丢失更新

假设两个事务同时修改同一行数据，若没有锁机制，第二个事务可能覆盖第一个事务的修改。通过排他锁可避免此问题：

-- 事务 A  
BEGIN;  
UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- 自动申请行级排他锁  
COMMIT;  

-- 事务 B  
BEGIN;  
UPDATE accounts SET balance = balance + 50 WHERE id = 1; -- 需等待事务 A 的锁释放  
COMMIT;  

此时，事务 B 必须等待事务 A 提交后才能执行更新。

场景 2：避免死锁

死锁是两个或多个事务相互等待对方释放锁而无法继续执行的情况。例如：

-- 事务 A  
BEGIN;  
UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- 持有 id=1 的排他锁  
-- 此时事务 B 发起操作  

-- 事务 B  
BEGIN;  
UPDATE accounts SET balance = balance - 50 WHERE id = 2; -- 持有 id=2 的排他锁  
UPDATE accounts SET balance = balance + 100 WHERE id = 1; -- 需等待事务 A 的锁  

若事务 A 后续尝试更新 id=2 的记录，将导致循环等待。此时 PostgreSQL 的死锁检测机制会终止其中一个事务，返回错误信息。

场景 3：优化并发查询

对于读多写少的场景，可通过共享锁提高并发性能：

BEGIN ISOLATION LEVEL READ COMMITTED;  
SELECT * FROM products WHERE category = 'electronics' FOR SHARE; -- 申请共享锁  
-- 其他事务可读取该数据，但无法修改  
COMMIT;  

锁的监控与诊断

1. 查看当前锁信息

PostgreSQL 提供了系统视图 pg_locks 和 pg_stat_activity，可用于诊断锁冲突：

SELECT  
    l.locktype,  
    l.relation::regclass AS table_name,  
    a.usename AS user_name,  
    a.query AS current_query,  
    age(now(), a.query_start) AS duration  
FROM pg_locks l  
JOIN pg_stat_activity a ON l.pid = a.pid  
WHERE NOT granted; -- 仅显示等待中的锁  

2. 分析锁等待链

当锁冲突复杂时，可使用 pg_locks 和 pg_blocking_pids 函数定位阻塞源头：

SELECT pg_blocking_pids( <<target_pid>> ); -- 返回阻塞目标进程的 PID 列表  

锁的优化策略与最佳实践

1. 减少锁持有时间

• 缩短事务执行时间：避免在事务中执行长时间计算或用户交互操作。
• 批量操作分批处理：例如分批次更新数据，而非一次性锁定全表。

2. 合理选择隔离级别

PostgreSQL 的 READ COMMITTED 和 REPEATABLE READ 隔离级别对锁行为有显著影响。例如，在 READ COMMITTED 下，行级锁在事务提交前不会释放；而 REPEATABLE READ 可能因间隙锁（Gap Lock）导致更广泛的锁定范围。

3. 使用索引优化行锁

通过为 WHERE 条件添加索引，可减少扫描范围，降低锁竞争概率。例如：

-- 在 orders 表的 order_date 列创建索引  
CREATE INDEX idx_orders_order_date ON orders(order_date);  

4. 避免不必要的显式锁

显式使用 LOCK TABLE 可能过度限制并发性。优先依赖 PostgreSQL 的自动锁机制，仅在必要时显式控制锁类型。

总结

PostgreSQL 的 LOCK（锁） 机制是数据库并发控制的核心工具，其合理应用直接影响系统的性能和数据一致性。通过理解锁的类型、冲突规则和典型场景，开发者可以避免常见的死锁、性能瓶颈问题。在实际开发中，建议结合监控工具和优化策略，平衡并发性和资源占用，从而构建高效可靠的数据库应用。

掌握锁机制不仅是 PostgreSQL 的进阶技能，更是分布式系统设计中的重要基础。希望本文能帮助读者建立起对锁机制的系统性认知，并在实践中灵活运用这些知识。