PostgreSQL阻塞查询分析与优化实战

1. 深入解析PostgreSQL阻塞查询问题

作为一名长期与PostgreSQL打交道的DBA，我经常遇到数据库突然变慢的情况。经过无数次深夜排查，发现阻塞查询(Blocking Queries)是最常见的性能杀手之一。这类查询会像交通堵塞一样，一个查询卡住，后面所有依赖相同资源的查询都会被堵住，最终导致整个系统响应迟缓。

PostgreSQL从9.6版本开始提供了pg_blocking_pids()这个利器，它能直接告诉我们哪些查询被谁阻塞了。下面这个查询是我在实战中总结出来的终极阻塞查询分析工具：

sql复制SELECT
  pid,
  usename,
  pg_blocking_pids(pid) AS blocked_by_pids,
  query AS blocked_query,
  now() - query_start AS duration,
  state
FROM
  pg_stat_activity
WHERE
  cardinality(pg_blocking_pids(pid)) > 0
ORDER BY
  duration DESC;

相比基础版本，我增加了两个关键字段：

• duration：显示查询已经被阻塞了多久，帮助我们判断问题的紧急程度
• state：显示查询的当前状态，特别是关注'idle in transaction'状态，这通常是长事务导致的阻塞

2. 查询核心组件深度解析

2.1 pg_stat_activity视图剖析

pg_stat_activity是PostgreSQL提供的系统视图，相当于数据库的"任务管理器"。它包含了每个后端进程的实时快照，主要字段包括：

• pid：进程ID，相当于操作系统的进程号
• usename：执行该查询的数据库用户名
• query：正在执行或最后执行的SQL语句
• state：当前状态（active, idle, idle in transaction等）
• query_start：查询开始时间
• backend_type：区分是客户端连接还是系统进程

重要提示：在生产环境查询pg_stat_activity时，建议使用LIMIT子句或通过WHERE条件过滤，因为该视图的查询本身也会消耗资源。

2.2 pg_blocking_pids()函数工作机制

这个函数是PostgreSQL 9.6引入的阻塞检测神器，它的工作原理是：

1. 检查目标进程(pid)正在等待的锁
2. 找出持有这些锁的其他进程
3. 返回这些阻塞进程的pid数组

函数返回的是一个数组类型，所以我们需要用cardinality()函数来判断数组长度。当长度大于0时，说明该进程正在被阻塞。

2.3 关键过滤条件解析

WHERE cardinality(pg_blocking_pids(pid)) > 0这个条件实现了：

1. 对pg_stat_activity中的每个进程，计算其阻塞进程数
2. 只保留至少被一个进程阻塞的记录
3. 结果集就是当前所有被阻塞的查询清单

3. 高级阻塞分析技巧

3.1 查找阻塞链

有时候阻塞会形成链条：A被B阻塞，B又被C阻塞。这时我们需要递归查询整个阻塞链：

sql复制WITH RECURSIVE blocking_chains AS (
  SELECT 
    pid,
    usename,
    pg_blocking_pids(pid) AS blockers,
    query,
    ARRAY[pid] AS chain,
    1 AS level
  FROM pg_stat_activity
  WHERE cardinality(pg_blocking_pids(pid)) > 0
  
  UNION ALL
  
  SELECT 
    a.pid,
    a.usename,
    pg_blocking_pids(a.pid),
    a.query,
    bc.chain || a.pid,
    bc.level + 1
  FROM pg_stat_activity a
  JOIN blocking_chains bc ON a.pid = ANY(bc.blockers)
)
SELECT * FROM blocking_chains
ORDER BY level, chain;

这个递归CTE可以显示完整的阻塞层级关系，帮助我们找到阻塞的源头。

3.2 锁定类型分析

PostgreSQL有多种锁类型，了解它们有助于针对性解决问题：

可以通过以下查询查看详细的锁信息：

sql复制SELECT lock.locktype, 
       lock.relation::regclass,
       lock.mode,
       lock.virtualtransaction,
       stat.usename,
       stat.query,
       stat.query_start,
       age(now(), stat.query_start) AS age
FROM pg_catalog.pg_locks lock
JOIN pg_stat_activity stat ON lock.pid = stat.pid
WHERE NOT lock.granted;

4. 阻塞问题解决方案库

4.1 常见阻塞场景及处理

1. 长事务阻塞

   • 现象：state显示'idle in transaction'
   • 解决方案：

     sql复制SELECT pg_terminate_backend(pid) FROM pg_stat_activity 
     WHERE state = 'idle in transaction' AND age(now(), state_change) > interval '5 minutes';
     

2. DDL锁等待

   • 现象：ALTER TABLE等操作被阻塞
   • 解决方案：在业务低峰期执行DDL，或使用LOCK_TIMEOUT参数

3. 外键约束检查

   • 现象：大批量数据导入时出现阻塞
   • 解决方案：先禁用外键约束，导入后再启用

4.2 预防性措施

1. 设置语句超时

   sql复制SET statement_timeout = '30s';  -- 单条SQL最长执行30秒
   

2. 监控长事务

   sql复制SELECT pid, usename, query, now() - xact_start AS duration
   FROM pg_stat_activity
   WHERE state LIKE '%transaction%'
   ORDER BY duration DESC;
   

3. 使用锁超时

   sql复制SET lock_timeout = '5s';  -- 获取锁等待最多5秒
   

5. 实战案例解析

5.1 案例一：批量更新导致的阻塞

场景：用户报告系统变慢，查询阻塞情况发现：

code复制 pid  | usename | blocked_by_pids |        duration        | state  
------+---------+-----------------+------------------------+--------
 5678 | appuser | {4321}          | 00:15:23.456789        | active

进一步查询pid=4321的进程：

sql复制SELECT query FROM pg_stat_activity WHERE pid = 4321;

发现是一个没有提交的批量UPDATE操作。解决方案：

1. 联系应用团队确认该批量更新是否可以终止
2. 如可终止，执行：

   sql复制SELECT pg_terminate_backend(4321);
   

3. 建议应用团队将大批量操作拆分为小批次

5.2 案例二：死锁问题

虽然本文主要讨论阻塞，但死锁(deadlock)是更严重的情况。PostgreSQL能自动检测死锁并中止其中一个事务，但我们可以在日志中看到类似信息：

code复制ERROR:  deadlock detected
DETAIL:  Process 1234 waits for ShareLock on transaction 5678; blocked by process 9012.
Process 9012 waits for ShareLock on transaction 3456; blocked by process 1234.

解决方案：

1. 分析日志中的查询模式
2. 确保事务中的操作顺序一致
3. 考虑使用显式锁来避免死锁

6. 性能优化进阶建议

6.1 索引优化

不合理的索引是导致阻塞的常见原因。检查缺失索引：

sql复制SELECT relname, seq_scan, seq_tup_read, idx_scan, 
       seq_tup_read/seq_scan AS avg_tuples_per_scan
FROM pg_stat_user_tables
WHERE seq_scan > 0
ORDER BY avg_tuples_per_scan DESC;

高avg_tuples_per_scan值表示表可能缺少合适索引。

6.2 连接池配置

不合理的连接池设置会导致连接堆积，增加阻塞概率。建议：

1. 设置合理的连接池大小
2. 使用连接池软件如pgbouncer
3. 配置连接超时：

ini复制[pgbouncer]
pool_mode = transaction
server_idle_timeout = 300

6.3 监控集成

将阻塞查询监控集成到现有监控系统：

bash复制# Nagios插件示例
#!/bin/bash
BLOCKED_COUNT=$(psql -U postgres -t -c "SELECT count(*) FROM pg_stat_activity WHERE cardinality(pg_blocking_pids(pid)) > 0")
if [ $BLOCKED_COUNT -gt 3 ]; then
  echo "CRITICAL: $BLOCKED_COUNT blocked queries detected"
  exit 2
fi

7. 版本兼容性说明

本文介绍的技术适用于PostgreSQL 9.6及以上版本。对于更早版本，可以使用以下替代方案：

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;

在实际运维中，我发现阻塞查询问题通常不是单纯的技术问题，而是反映了应用逻辑或架构设计上的不足。定期审查阻塞模式，与开发团队共同优化应用设计，才是保持数据库长期健康运行的关键。