postgresql锁等待如何解除_postgresql死锁与阻塞处理-SQL-PHP中文网

postgresql锁等待如何解除_postgresql死锁与阻塞处理

冰川箭仙

发布： 2025-11-23 22:36:07

原创

463人浏览过

锁等待和死锁由并发事务争用资源引起，可通过pg_locks和pg_stat_activity视图查询阻塞进程及SQL，定位后使用pg_terminate_backend终止会话或优化事务逻辑、索引与隔离级别；死锁由系统自动检测并回滚一事务，需应用重试；预防措施包括设置statement_timeout、监控长事务、优化慢查询及合理设计业务流程。

postgresql锁等待如何解除_postgresql死锁与阻塞处理

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) 强制结束长时间运行或异常的事务。

SELECT pg_terminate_backend(12345); -- 替换为实际的PID

登录后复制

优化事务逻辑：避免长事务，尽量减少事务中包含的操作数量，及时提交或回滚。
调整隔离级别：在允许的情况下使用较低的隔离级别（如 Read Committed），减少锁竞争。
索引优化：确保查询走索引，避免全表扫描带来的大量行锁或页锁。

处理死锁

PostgreSQL具备自动检测死锁的能力。一旦发现两个或多个事务互相等待对方持有的锁，系统会主动中断其中一个事务，抛出错误：

Revid AI

AI短视频生成平台

查看详情

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 的稳定性和响应能力。

以上就是postgresql锁等待如何解除_postgresql死锁与阻塞处理的详细内容，更多请关注php中文网其它相关文章！