PostgreSQL并行查询与并行顺序扫描调优：大表查询加速实战

PostgreSQL并行查询架构基础

PostgreSQL从9.6开始引入并行查询，到16/17版本已经支持并行顺序扫描、并行索引扫描、并行聚合、并行JOIN等多种执行路径。并行查询的核心架构：Gather节点作为协调者，启动多个Background Worker进程并行扫描数据分片，各Worker独立执行Scan和部分计算，结果汇总到Leader进程做最终合并。理解这个架构是调优的基础——并行不是魔法，它用CPU多核换I/O等待时间，前提是查询确实受I/O瓶颈限制。

并行相关参数配置

PostgreSQL并行查询受5个核心参数控制，它们的配合关系决定了并行度上限：

-- 最大并行Worker数（全局）
max_parallel_workers = 8

-- 每个Gather节点最大并行Worker数
max_parallel_workers_per_gather = 4

-- 触发并行的最小表数据量
min_parallel_table_scan_size = 8MB

-- 触发并行的最小成本阈值
parallel_tuple_cost = 0.01
parallel_setup_cost = 1000

-- 并行Worker的成本系数
-- 越小越倾向选择并行计划
parallel_tuple_cost = 0.01

关键调优思路：max_parallel_workers_per_gather是单查询并行度的硬上限，通常设为CPU核心数的一半；parallel_setup_cost越高，优化器越不愿意选择并行计划——对于确认受I/O限制的大表查询，适当降低此值：

-- 对大表查询频繁的数据库调整
ALTER SYSTEM SET parallel_setup_cost = 200;
ALTER SYSTEM SET parallel_tuple_cost = 0.001;
ALTER SYSTEM SET max_parallel_workers_per_gather = 6;
SELECT pg_reload_conf();

并行顺序扫描的执行计划分析

验证并行查询是否生效，最直接的方式是EXPLAIN ANALYZE：

EXPLAIN ANALYZE
SELECT count(*), status
FROM orders
WHERE created_at >= '2025-01-01'
GROUP BY status;

-- 预期输出关键行：
-- Finalize GroupAggregate
--   ->  Gather Merge
--         Workers Planned: 4
--         Workers Launched: 4
--           ->  Partial GroupAggregate
--                 ->  Parallel Seq Scan on orders

-- 如果看到 Workers Launched: 1
-- 说明并行未实际启动

Workers Launched少于Workers Planned的常见原因：max_parallel_workers被其他查询占满；表数据量未达到min_parallel_table_scan_size；表上有排他锁阻塞Worker启动。

并行聚合与并行索引扫描

并行聚合（Parallel Aggregation）分两阶段执行：Worker各自做Partial Aggregate，Leader做Finalize Aggregate合并部分结果。这对COUNT/SUM/AVG类聚合效果显著，但对DISTINCT聚合支持有限——DISTINCT需要在Finalize阶段去重，无法在Partial阶段完成。

-- 并行聚合生效的查询
EXPLAIN (FORMAT JSON)
SELECT avg(amount), count(*)
FROM orders
WHERE created_at >= '2025-01-01';

-- 并行索引扫描
SET enable_seqscan = off;  -- 强制走索引
EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = 12345
ORDER BY created_at DESC
LIMIT 50;

并行索引扫描要求索引是B-tree类型，且查询条件能利用索引的前缀列。GiST和GIN索引目前不支持并行扫描。

并行查询的适用边界与陷阱

并行查询不是万能的。以下场景并行反而降低性能：结果集很小的查询——并行Worker启动开销大于扫描节省的时间；大量锁争用的OLTP场景——并行Worker会加剧锁竞争；CTE和子查询内部——PostgreSQL对CTE的并行支持有限，materialized CTE不会并行执行；带有RETURNING的DML——INSERT/UPDATE/DELETE的RETURNING子句会阻止并行。

排查并行查询未生效的完整检查清单：

-- 1. 确认并行参数
SELECT name, setting FROM pg_settings
WHERE name LIKE 'parallel%'
   OR name = 'max_worker_processes';

-- 2. 确认表统计信息是否准确
ANALYZE orders;

-- 3. 确认是否有锁阻塞
SELECT locktype, relation::regclass, mode, pid
FROM pg_locks
WHERE NOT granted;

-- 4. 强制启用并行验证
SET max_parallel_workers_per_gather = 4;
SET parallel_setup_cost = 0;
EXPLAIN ANALYZE SELECT count(*) FROM orders;

生产环境并行调优的渐进策略

生产环境调整并行参数应采用渐进策略：先在只读副本上调整参数并跑基准测试；确认无性能回退后逐步应用到主库；监控pg_stat_activity中的parallel worker使用情况，避免并行Worker耗尽导致查询降级为串行执行。

-- 监控并行Worker使用
SELECT query,
  CASE WHEN query LIKE '%Parallel Seq Scan%'
       THEN 'parallel' ELSE 'serial' END AS exec_mode
FROM pg_stat_activity
WHERE state = 'active';

-- 查询级并行设置（不修改全局参数）
SET LOCAL max_parallel_workers_per_gather = 8;
SELECT /*+ Parallel(orders 4) */ count(*)
FROM orders;

SET LOCAL只在事务内生效，不影响其他会话。这为关键查询提供了临时提升并行度的安全路径。