PostgreSQL 的并行查询从 9.6 版本开始引入，最初只支持并行顺序扫描，后续版本逐步加入并行聚合、并行连接以及并行索引扫描能力。它的核心思路是把一个大查询拆分成多个可独立执行的子任务，交给若干后台工作进程同时处理，再由领导进程合并结果。对于数据量达到数千万行的表，如果只执行分组统计或范围过滤，单进程查询通常只能打满一个 CPU 核心，而启用并行查询后，多个核心可以同时扫描不同数据块并计算局部结果，整体执行时间往往会明显下降。理解这些工作进程如何被调度、受哪些参数影响，是调优复杂 SQL 的前提。
一、并行查询的触发条件与执行计划特征
并行查询并不是只要表很大就一定会启用。规划器会先检查表大小是否达到 min_parallel_table_scan_size 的阈值，如果表或索引过小，启动并行进程带来的额外开销可能高于收益，因此不会生成并行计划。其次，SQL 中涉及的函数和操作符必须被标记为 parallel safe，否则无法安全地分发给 worker 进程执行。满足这些条件后，优化器会比较串行计划和并行计划的估算成本，只有并行成本更低时才会选择并行方案。
在 EXPLAIN 输出中，并行计划通常会出现 Gather 或 Gather Merge 节点，它负责接收 worker 进程返回的局部结果。Gather 节点的子节点往往是 Partial 开头的节点，例如 Partial Aggregate 或 Partial Seq Scan。通过观察 Workers Planned 与 Workers Launched，可以判断计划期望的并行度以及实际启动的 worker 数量。如果 Launched 明显小于 Planned，通常说明实例的并行 worker 池已经耗尽，需要检查 max_worker_processes 和 max_parallel_workers 的配置。
EXPLAIN (ANALYZE, BUFFERS) SELECT category, count(*) FROM large_orders WHERE created_at >= '2024-01-01' GROUP BY category;
二、关键并行参数与配置思路
影响并行度的核心参数是 max_parallel_workers_per_gather，它限制单个 Gather 节点最多可以使用的后台工作进程数。默认值是 2，对于拥有 8 核或 16 核 CPU 的服务器，这个值通常可以调高到 4 或 6。但要注意，该参数只是单条 SQL 的上限，多条并发查询会共享实例级的 max_parallel_workers 池，如果总 worker 数不足，后续查询的并行度会被迫降低。因此调优时需要同时考虑单查询并行度和全局并发负载。
另一个容易忽略的参数是 min_parallel_table_scan_size，它控制表至少多大才会考虑并行顺序扫描。如果默认的 8MB 阈值太高，一些中等规模表可能永远不会走并行扫描，但这些表在复杂连接中仍然可能拖慢整体性能。对于在线事务与报表混合的库，可以结合业务情况适当降低该阈值，让优化器有更多机会生成并行计划。代价是并行启动开销会被平摊到更多小查询上，有时反而增加调度成本。
ALTER SYSTEM SET max_parallel_workers_per_gather = 4; ALTER SYSTEM SET max_parallel_workers = 16; ALTER SYSTEM SET max_parallel_maintenance_workers = 4; ALTER SYSTEM SET min_parallel_table_scan_size = '4MB'; SELECT pg_reload_conf();
成本类参数同样影响并行计划的生成。降低 parallel_setup_cost 和 parallel_tuple_cost 可以鼓励优化器选择并行执行，但如果设置过低，原本更适合串行的小查询也可能被强制并行，造成性能波动。维护操作如创建索引和 VACUUM 可以通过 max_parallel_maintenance_workers 独立控制，这类操作从并行中获得的收益通常比查询更稳定。配置完成后建议使用 pg_settings 视图确认参数已生效，而不是只修改配置文件后忘记 reload。
SELECT name, setting, unit
FROM pg_settings
WHERE name IN ('max_parallel_workers_per_gather',
'max_parallel_workers',
'min_parallel_table_scan_size');
三、实际加速效果与限制分析
并行查询的加速效果并不是线性增长的。以常见的单表分组聚合为例，假设一张 5000 万行的订单表执行按类目统计，串行扫描需要 18 秒，将并行度从 0 调整为 4 后，执行时间可能降到 6 秒左右；但如果继续把并行度调到 8，耗时也许只降到 5 秒，因为 leader 进程汇总结果、磁盘 I/O 带宽以及共享缓冲区竞争开始成为瓶颈。因此建议从低并行度开始测试，逐步调整，而不是一次性将参数调到 CPU 核数。
还有一个重要限制是内存消耗。多个 worker 进程会同时进行排序、哈希聚合或连接，每个 worker 都会使用自己的 work_mem 分配内存。如果 work_mem 设置为 64MB，4 个 worker 可能额外占用 256MB 以上的内存，再加上其他并发查询，系统很容易出现内存压力。对于内存有限的实例，可以在开启并行前适当降低 work_mem，或者为并行维护操作单独设置较小的内存参数。与此同时，涉及扩展协议、某些 PL/pgSQL 函数或自定义 C 函数的查询可能无法使用并行，需要在实际执行计划中确认是否出现 Gather 节点。
判断并行是否真正生效，建议同时观察执行时间和执行计划中的 Workers Launched。如果 Workers Launched 经常为 0，而 Workers Planned 大于 0，说明 worker 进程没有成功启动，问题往往出在 max_worker_processes 已经用完，或被其他数据库、逻辑复制等占用。此时只调高 max_parallel_workers_per_gather 无效，必须提高实例级进程上限并重启数据库。另一个常见误区是认为所有节点类型都支持并行，事实上某些不常见的聚合函数、自定义操作符或子查询结构可能仍会回退到串行执行。
四、实操验证与调优步骤
为了直观观察并行带来的变化，可以先用 generate_series 创建一张几千万行的测试表，然后在同一会话中切换并行度，比较执行时间。先在关闭并行的情况下执行一次聚合查询，再开启并行执行相同 SQL。由于数据会被缓存，第二次查询可能比第一次快，因此测试时应使用 EXPLAIN ANALYZE 关注实际扫描耗时，或通过重启实例刷新缓存后分别测试。
CREATE TABLE t_parallel_demo AS
SELECT g AS id,
(random() * 10000)::int AS category,
md5(g::text) AS payload
FROM generate_series(1, 50000000) AS g;
SET max_parallel_workers_per_gather = 0;
EXPLAIN (ANALYZE, TIMING OFF, SUMMARY OFF)
SELECT category, count(*)
FROM t_parallel_demo
WHERE category < 100
GROUP BY category;
SET max_parallel_workers_per_gather = 6;
EXPLAIN (ANALYZE, TIMING OFF, SUMMARY OFF)
SELECT category, count(*)
FROM t_parallel_demo
WHERE category < 100
GROUP BY category;
上述示例中，开启并行后可以在执行计划底部看到类似 Gather 以及 Workers Planned: 6 的信息，执行时间也会明显缩短。但需要注意，如果过滤条件的选择性过高、返回行数很少，并行扫描的大部分数据都会在局部聚合后被丢弃，收益可能并不明显。此时优化器可能仍然选择并行，因为成本估算基于统计信息，而实际执行中 leader 合并开销可能超过收益。遇到这种情况，可以尝试调高 parallel_setup_cost 或降低表统计信息的 autoanalyze 频率，让规划器做出更准确的选择。
调优过程应该是反复观察执行计划、系统 CPU 利用率和查询延迟的过程。没有一个固定参数值适合所有业务库。一般来说，OLAP 报表库适合更高的并行度，因为查询通常复杂且运行时间长；而高并发 OLTP 系统应保持较低并行度，避免 worker 进程争抢 CPU 影响事务延迟。通过比较相同 SQL 在串行和并行下的实际执行时间，再结合 pg_stat_statements 统计，可以逐步找到适合当前负载的并行配置。
PostgreSQL并行查询并行度配置查询加速修改时间：2026-09-26 23:00:34