锁等待和死锁由并发事务争用资源引起，可通过pg_locks和pg_stat_activity视图查询阻塞进程及SQL，定位后使用pg_terminate_backend终止会话或优化事务逻辑、索引与隔离级别；死锁由系统自动检测并回滚一事务，需应用重试；预防措施包括设置statement_timeout、监控长事务、优化慢查询及合理设计业务流程。
PostgreSQL中出现锁等待或死锁，通常是由于多个事务并发操作相同的数据行或表导致的。当一个事务长时间持有锁，其他事务就需要等待，严重时会引发阻塞甚至死锁。这类问题会影响数据库性能，甚至导致应用卡顿或超时。
查看锁等待情况
要排查锁等待，首先要了解当前数据库中的锁状态。可以通过系统视图 pg_locks 和 pg_stat_activity 获取相关信息：
SELECT
blocked_locks.pid AS blocked_pid,
blocked_activity.usename AS blocked_user,
blocking_locks.pid AS blocking_pid,
blocking_activity.usename AS blocking_user,
blocked_activity.query AS blocked_query,
blocking_activity.query AS blocking_query,
NOW() - blocked_activity.query_start AS blocked_duration
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_locks.pid = blocked_activity.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_locks.pid = blocking_activity.pid
WHERE NOT blocked_locks.granted;
该查询能列出被阻塞的进程、阻塞它的进程、执行的SQL语句以及等待时间。通过这些信息可以快速定位“罪魁祸首”。
解除锁等待的方法
确认了造成阻塞的会话后，可以根据实际情况选择以下方式解除：
-
终止阻塞会话：使用
pg_terminate_backend(pid)强制结束长时间运行或异常的事务。 - 优化事务逻辑：避免长事务，尽量减少事务中包含的操作数量，及时提交或回滚。
- 调整隔离级别：在允许的情况下使用较低的隔离级别（如 Read Committed），减少锁竞争。
- 索引优化：确保查询走索引，避免全表扫描带来的大量行锁或页锁。
SELECT pg_terminate_backend(12345); -- 替换为实际的PID
处理死锁
PostgreSQL具备自动检测死锁的能力。一旦发现两个或多个事务互相等待对方持有的锁，系统会主动中断其中一个事务，抛出错误：
ERROR: deadlock detected DETAIL: Process 12345 waits for ShareLock on transaction 67890; blocked by process 6789. Process 6789 waits for ShareLock on transaction 12345; blocked by process 12345. HINT: See server log for query details.
被中断的事务需要由应用程序捕获异常并进行重试。这是正常机制，无需人工干预。
为减少死锁发生，建议：
- 所有事务按相同顺序访问表和行。
- 避免在事务中执行用户交互操作。
- 使用
FOR UPDATE或FOR SHARE显式加锁时要谨慎。
预防锁问题的最佳实践
与其事后处理，不如提前防范：
- 设置语句超时：
statement_timeout = '30s'防止 SQL 执行过久。 - 监控长期运行的事务：
SELECT * FROM pg_stat_activity WHERE now() - query_start > '5 minutes'::interval; - 定期分析慢查询日志，优化高频更新语句。
- 合理设计业务逻辑，避免在事务中调用外部服务。
基本上就这些。锁等待和死锁在高并发场景下难以完全避免，关键是快速发现、准确定位、及时响应。掌握上述方法，能有效提升 PostgreSQL 的稳定性和响应能力。
