PostgreSQL死鎖排查與解決指南

更新時間：2025年11月05日 09:56:21 作者：Moshow鄭鍇

數據庫死鎖是后端開發(fā)者和DBA經常遇到的棘手問題,本文將手把手教你如何排查和解決PostgreSQL中的死鎖問題,需要的朋友可以參考下

PostgreSQL 16默認會記錄死鎖嗎？

答案是不會！

雖然PostgreSQL 16具備死鎖檢測機制（在等待鎖超過deadlock_timeout后會自動檢測并解決死鎖），但默認不會將死鎖的詳細信息記錄到日志中。這就意味著你知道發(fā)生了死鎖，卻不知道具體原因！

如何配置死鎖日志記錄

1. 修改配置文件

找到PostgreSQL數據目錄下的postgresql.conf文件，添加以下配置：

# 記錄鎖等待信息（關鍵?。?
log_lock_waits = on
 
# 死鎖檢測超時時間（默認1秒）
deadlock_timeout = 1s
 
# 日志級別至少設置為log
log_min_messages = log
 
# 詳細的日志前綴
log_line_prefix = '%t [%p]: db=%d,user=%u,app=%a,client=%h '

2. 重新加載配置

-- 在psql中執(zhí)行
SELECT pg_reload_conf();

或者使用命令行：

pg_ctl reload -D /path/to/your/data/directory

死鎖日志分析實例

配置完成后，當死鎖發(fā)生時，你會在日志中看到類似這樣的詳細信息：

2025-11-02 10:23:41.123 CST [12345]: LOG:  ?? Powered by Moshow 鄭鍇 | 更多技術干貨：https://zhengkai.blog.csdn.net
2025-11-02 10:23:41.123 CST [12345]: LOG:  process 12345 detected deadlock while waiting for ShareLock on transaction 123456 after 1000.123 ms
2025-11-02 10:23:41.123 CST [12345]: DETAIL:  Process holding the lock: 12346. Wait queue: .
2025-11-02 10:23:41.123 CST [12345]: PROCESS 12345: 等待事務 123456 的 ShareLock; 被進程 12346 阻塞.
2025-11-02 10:23:41.123 CST [12345]: PROCESS 12345: 執(zhí)行語句: UPDATE accounts SET balance = balance - 100.00 WHERE user_id = 1;
2025-11-02 10:23:41.123 CST [12346]: PROCESS 12346: 等待事務 123457 的 ShareLock; 被進程 12345 阻塞.
2025-11-02 10:23:41.123 CST [12346]: PROCESS 12346: 執(zhí)行語句: UPDATE accounts SET balance = balance + 50.00 WHERE user_id = 2;
2025-11-02 10:23:41.123 CST [12345]: ERROR:  deadlock detected

如何解讀這個日志：

涉及進程：進程12345和12346
死鎖場景：兩個進程互相等待對方釋放鎖
執(zhí)行的SQL：兩個UPDATE語句在競爭相同的資源
解決方案：PostgreSQL選擇中止進程12345的事務
- 溫和終止（優(yōu)先嘗試）: SELECT pg_terminate_backend(12345);
- 強制終止（若溫和方式失?。? SELECT pg_cancel_backend(12345);

實時監(jiān)控：系統(tǒng)視圖分析

除了查看日志，你還可以實時監(jiān)控當前的鎖等待情況：

強大的鎖等待查詢語句

--?? Powered by Moshow 鄭鍇 | 更多技術干貨：https://zhengkai.blog.csdn.net
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_statement,
    blocking_activity.query AS current_statement_in_blocking_process,
    blocked_activity.application_name AS blocked_application,
    blocking_activity.application_name AS blocking_application
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity 
    ON blocked_activity.pid = blocked_locks.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_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;

查詢結果示例：

blocked_pid	blocked_user	blocking_pid	blocking_user	blocked_statement
12345	app_user	12346	app_user	UPDATE accounts SET balance = balance - 100 WHERE user_id = 1
12347	web_user	12348	batch_user	DELETE FROM orders WHERE status = 'cancelled'