1. 项目概述：PostgreSQL阻塞查询识别与优化
在数据库运维的日常工作中，最令人头疼的莫过于系统突然变慢，而罪魁祸首往往是一个未被发现的阻塞查询。PostgreSQL作为最先进的开源关系型数据库，虽然性能优异，但也难免会遇到查询阻塞导致的性能瓶颈。通过pg_stat_activity系统视图，我们可以像专业DBA一样快速定位问题源头。
我管理过多个TB级PostgreSQL集群，发现90%的数据库性能问题都源于未被及时发现的阻塞查询。这些"隐形杀手"可能是一个忘记加索引的全表扫描，也可能是一个长时间运行的事务锁住了关键资源。学会使用pg_stat_activity进行实时诊断，是每个PostgreSQL使用者的必备技能。
2. 核心原理与技术解析
2.1 PostgreSQL并发控制机制
PostgreSQL采用多版本并发控制(MVCC)机制来处理并发事务。当出现阻塞时，通常是因为：
- 锁冲突：一个事务持有锁而另一个事务在等待
- 资源竞争：CPU、内存或I/O资源不足
- 长事务：未及时提交/回滚的事务持有锁过久
MVCC虽然减少了读-写冲突，但写-写冲突仍需要通过锁来解决。理解这一点对分析阻塞场景至关重要。
2.2 pg_stat_activity视图详解
pg_stat_activity是PostgreSQL提供的实时监控视图，包含以下关键字段：
sql复制SELECT
pid, -- 进程ID
usename, -- 用户名
application_name, -- 应用名称
client_addr, -- 客户端IP
backend_start, -- 连接开始时间
xact_start, -- 事务开始时间
query_start, -- 查询开始时间
state, -- 状态(active/idle等)
wait_event_type, -- 等待事件类型
wait_event, -- 等待的具体事件
query -- 正在执行的SQL
FROM pg_stat_activity;
这个视图就像数据库的"心电图"，能实时反映每个连接的健康状况。
3. 阻塞查询识别实战
3.1 基础识别方法
最简单的阻塞查询识别SQL：
sql复制SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.query AS blocked_query,
blocking_activity.query AS blocking_query
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;
这个查询会返回所有被阻塞的进程及其阻塞者，是诊断阻塞问题的"瑞士军刀"。
3.2 高级分析方法
对于更复杂的阻塞场景，我推荐使用这个增强版查询：
sql复制WITH blocking AS (
SELECT pid, locktype, relation::regclass, mode, granted
FROM pg_locks
WHERE granted = true
),
waiting AS (
SELECT pid, locktype, relation::regclass, mode, granted
FROM pg_locks
WHERE granted = false
)
SELECT
w.pid AS waiting_pid,
w.mode AS waiting_mode,
b.pid AS blocking_pid,
b.mode AS blocking_mode,
b.relation AS blocked_table,
now() - a.query_start AS waiting_duration,
a.query AS waiting_query,
a2.query AS blocking_query
FROM waiting w
JOIN blocking b ON
w.locktype = b.locktype AND
w.relation = b.relation AND
w.pid != b.pid
JOIN pg_stat_activity a ON w.pid = a.pid
JOIN pg_stat_activity a2 ON b.pid = a2.pid
ORDER BY waiting_duration DESC;
这个查询增加了等待时长排序和更多锁信息，能更全面地分析阻塞情况。
4. 性能优化与问题解决
4.1 常见阻塞场景与解决方案
-
长事务阻塞DDL操作
- 现象：ALTER TABLE等DDL语句被阻塞
- 解决方案：先终止长事务或等业务低峰期执行
-
未提交事务阻塞其他写操作
- 现象：UPDATE/DELETE被阻塞
- 解决方案：设置事务超时参数(idle_in_transaction_session_timeout)
-
锁升级导致死锁
- 现象：多个查询相互阻塞
- 解决方案：调整锁获取顺序或使用SKIP LOCKED
4.2 预防性措施
-
参数调优建议：
sql复制-- 设置空闲事务超时(单位毫秒) SET idle_in_transaction_session_timeout = '5min'; -- 设置语句超时 SET statement_timeout = '30s'; -
索引优化：
- 确保频繁查询的字段有合适索引
- 定期分析查询计划，优化慢查询
-
应用层优化：
- 避免在事务中执行耗时操作(如网络请求)
- 使用连接池管理数据库连接
5. 监控与自动化处理
5.1 创建阻塞监控视图
建议创建一个专用视图来监控阻塞情况：
sql复制CREATE OR REPLACE VIEW blocking_queries AS
SELECT
blocked.pid AS blocked_pid,
blocked.usename AS blocked_user,
blocked.query AS blocked_query,
blocking.pid AS blocking_pid,
blocking.usename AS blocking_user,
blocking.query AS blocking_query,
now() - blocked.query_start AS blocked_duration
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked ON blocked.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 ON blocking.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
5.2 自动化处理脚本
对于严重的阻塞情况，可以设置自动化处理：
bash复制#!/bin/bash
# 检测阻塞超过5分钟的情况
BLOCKED=$(psql -U postgres -d your_db -t -c "
SELECT blocked_pid FROM blocking_queries
WHERE blocked_duration > interval '5 minutes'
LIMIT 1")
if [ -n "$BLOCKED" ]; then
# 终止被阻塞的查询(根据业务需求选择终止阻塞者或被阻塞者)
psql -U postgres -d your_db -c "
SELECT pg_terminate_backend(blocking_pid)
FROM blocking_queries
WHERE blocked_duration > interval '5 minutes'"
# 发送告警通知
echo "Blocking queries terminated at $(date)" | mail -s "PostgreSQL Blocking Alert" admin@example.com
fi
6. 实战经验与避坑指南
-
锁类型识别技巧：
- AccessShareLock：SELECT语句获取的锁
- RowExclusiveLock：UPDATE/DELETE获取的锁
- ShareLock：CREATE INDEX获取的锁
- ExclusiveLock：ALTER TABLE获取的锁
-
常见误区：
- 不要盲目终止进程，先确认业务影响
- 注意锁等待与资源等待的区别
- 监控系统负载，区分是锁问题还是资源问题
-
高级诊断工具：
sql复制-- 查看锁等待图 SELECT * FROM pg_lock_status(); -- 查看锁统计信息 SELECT * FROM pg_stat_locks; -
性能优化黄金法则：
- 事务要短小精悍
- 查询要精确命中索引
- 批量操作要分批次处理
- 定期维护数据库统计信息
在实际运维中，我发现80%的阻塞问题都可以通过优化应用代码和合理设置超时参数来预防。特别是对于那些使用ORM框架的应用，要特别注意它生成的SQL是否高效。我曾经遇到一个案例，Django的默认事务行为导致了一个简单的页面查询阻塞了整个表的更新操作，通过设置AUTOCOMMIT和优化查询才最终解决。