PostgreSQL 中识别并终止死锁进程的方法

结果与目标

在处理数据库性能问题时，最常见的情形是某条 SQL 语句长期挂起，阻碍其他事务执行。我们的目标是快速找出引发阻塞的会话 ID，并将其强制结束，从而让后续的更新或查询能顺利执行。

准备条件

• 已安装并运行 PostgreSQL 服务。
• 拥有连接数据库的权限（通常需具备 superuser 或特定角色权限才能查看其他用户的进程活动）。
• 掌握要操作的数据库名称。

真实操作顺序

第1步：检索出死锁进程的ID

首先，我们需要进入数据库命令行客户端（如 psql）或通过应用程序连接的数据库接口执行查询。

目的：从当前活动的会话列表中，筛选出属于特定数据库且处于等待状态的数据行。

入口：SQL 查询窗口。

动作：执行以下 SQL 语句。请将占位符替换为实际的数据库名：

SELECT * FROM pg_stat_activity WHERE datname='需要排查的数据库名';

重要参数：datname 字段用于过滤特定库，若无特定限制可省略该 WHERE 条件。

完成状态判断：观察返回的结果集。重点关注 wait_event_type 或旧版本中的 waiting 字段。如果该字段的值为 t（true）或显示明确的锁事件（如 Lock），则该行对应的记录即为疑似死锁或阻塞源。

同时，记录下该行中的 pid 列的值（在较新版本的 PG 中，原 procpid 已更名为 pid）。这就是我们要杀掉的进程 ID。

第2步：将进程杀掉

找到目标 PID 后，选择适当的终止函数进行操作。

目的：主动中断正在运行的后台查询，释放被占用的资源。

入口：SQL 命令输入区。

动作：执行 cancel 命令。注意此方法主要针对长运行的普通查询或非致命阻塞：

SELECT pg_cancel_backend(填入上一步查到的 pid值);

可观察结果：执行完毕后，再次尝试之前报错或卡住的操作（例如更新那张表）。如果 SQL 提示成功执行或数据正常变更，说明阻塞已被解除。

第3步：备选方案（可选）

如果在大多数常规场景下 pg_cancel_backend 无效，或者你需要更强力地终止一个可能已陷入僵局的后台进程，可以使用 pg_terminate_backend()。

SELECT pg_terminate_backend(pid值);

风险提示：相比于 cancel，terminate 是直接关闭后端连接，可能会中断该连接正在进行的所有未完成事务。除非确定是死锁源头且不再需要该会话的状态，否则建议优先使用前者。

原文有依据的排错

若上述操作后，相关表依然无法更新，请检查：

1. 是否还有其他进程也在等待同一个资源（多重死锁链）？此时可能需要循环检测多次。
2. 是否存在外部应用层面的锁（如文件系统锁、网络锁）而非数据库内部锁？
3. 确认使用的 PostgreSQL 版本 API 差异，老版本 (<9.2) 使用 procpid，新版本统一使用 pid。

简要总结

通过监控 pg_stat_activity 视图，我们可以精准捕捉到造成瓶颈的死锁点；再利用 pg_cancel_backend 等管理函数进行干预，能有效解决因单点阻塞引发的全局卡顿问题。日常维护中保留对该工具的使用意识，有助于提升数据库运维效率。

以上就是 PostgreSQL 中识别并终止死锁进程的详细内容，更多关于 PostgreSQL 性能调优与故障排除的资料请关注本站其它相关文章！