文章目录一、并行查询概述1.1 为什么需要并行查询1.2 核心理念1.3 支持的并行操作类型1.4 并行查询的核心价值1.5 常用命令参考二、并行查询的执行模型2.1 进程角色2.2 通信机制2.3 执行计划中的标识Gather 节点三、关键配置参数详解3.1 全局资源限制需谨慎调整3.2 单查询并行度控制3.3 并行决策成本模型3.4 其他控制参数四、并行度的确定规则五、并行查询的限制与不支持场景5.1 查询类型限制5.2 算子限制5.3 函数与表达式限制5.4 资源与配置限制六、性能调优与监控6.1 监控并行执行6.2 调优建议6.3 避免过度并行七、实战案例7.1 场景分析 10 亿行订单表在现代数据库系统中硬件资源的充分利用是提升性能的关键。PostgreSQL 自 9.6 版本起引入了并行查询Parallel Query功能使得单条 SQL 查询能够利用多个 CPU 核心协同工作显著加速对大规模数据的扫描、连接与聚合操作。这一机制尤其适用于数据仓库、报表分析、ETL 等 OLAP 场景。本文将从设计思想、执行模型、支持的操作类型、关键参数、调优策略、限制条件及实战案例七个维度全面深入剖析 PostgreSQL 并行查询的核心原理与应用方法。一、并行查询概述1.1 为什么需要并行查询传统 PostgreSQL 查询由单个“后端进程”backend process顺序执行。当面对数十亿行的大表时即使 I/O 被操作系统缓存或 SSD 加速CPU 成为瓶颈——因为解析元组、计算表达式、执行过滤条件等操作均需消耗 CPU 周期。而现代服务器普遍配备 16 核、32 核甚至更多 CPU 核心。若仅用一个核心处理查询其余核心闲置资源利用率极低。并行查询的目标是将可分解的查询任务拆分为多个子任务分配给多个工作进程worker processes并行执行由主进程leader汇总结果在不改变 SQL 语义的前提下实现近线性的性能提升。1.2 核心理念透明性用户无需修改 SQL优化器自动决定是否启用并行。安全性仅对“并行安全”parallel-safe的操作启用避免数据竞争。可控性通过参数精细控制并行度防止资源耗尽。最小侵入在现有执行器架构上扩展保持兼容性。1.3 支持的并行操作类型并非所有查询操作都能并行。PostgreSQL 逐步扩展了支持范围PostgreSQL 版本新增并行能力9.6并行顺序扫描Seq Scan、并行聚合Aggregate、并行嵌套循环连接Nested Loop Join10并行位图堆扫描Bitmap Heap Scan、并行索引扫描Index Scan、并行 Index-Only Scan11并行 Hash Join、并行 Append分区表剪枝后并行扫描各分区12更多算子优化如并行 Window Function有限支持典型支持场景并行顺序扫描Parallel Seq Scan大表全表扫描按数据块范围划分给多个 Worker。并行聚合Parallel AggregateWorker 执行局部聚合Partial AggregateLeader 执行最终聚合Finalize Aggregate适用于COUNT,SUM,AVG等可分解聚合函数。并行连接Parallel Join支持 Hash Join、Nested Loop通常一方表并行扫描另一方广播或分区。并行索引扫描对大索引进行分段扫描需索引支持并行遍历。分区表并行扫描每个分区可由独立 Worker 扫描天然适合并行。1.4 并行查询的核心价值PostgreSQL 的并行查询是一项成熟且高效的性能优化技术其核心价值在于自动化优化器智能决策无需改写 SQL可扩展随 CPU 核数增加而提升吞吐精细化控制通过参数与表级设置灵活调整安全可靠严格限制于只读、并行安全的操作。然而并行并非银弹。DBA 需理解其原理、限制与成本模型在合适的场景大表、复杂聚合、低并发下启用并通过监控与测试验证效果。1.5 常用命令参考-- 查看当前并行参数SHOWmax_parallel_workers_per_gather;SHOWmin_parallel_table_scan_size;-- 会话级启用并行测试用SETmax_parallel_workers_per_gather4;-- 为表指定并行度ALTERTABLElarge_tableSET(parallel_workers6);-- 查看表统计信息含 reltuplesSELECTschemaname,tablename,n_tup_ins,n_tup_updFROMpg_stat_user_tablesWHEREtablenamelarge_table;二、并行查询的执行模型PostgreSQL 的并行查询采用“Leader-Worker” 模型2.1 进程角色Leader 进程即原始查询会话对应的后端进程负责查询规划、启动 Worker、收集结果、执行非并行部分如最终聚合可选择是否参与实际数据扫描由parallel_leader_participation控制。Worker 进程由 Leader 动态创建的后台工作进程Background Worker执行分配给它的子计划如扫描某段数据块通过共享内存队列shm_mq将结果元组发送给 Leader。2.2 通信机制使用共享内存消息队列Shared Memory Message Queue, shm_mq实现 Leader 与 Worker 之间的高效通信。每个 Worker 有两个队列一个用于返回元组一个用于上报错误信息。避免频繁的进程间 IPC 开销提升吞吐。2.3 执行计划中的标识Gather 节点当查询使用并行时执行计划中会出现Gather或Gather Merge节点GatherWorker 返回无序结果Leader 直接收集Gather MergeWorker 返回已排序结果Leader 执行多路归并用于ORDER BY场景。例如Gather Workers Planned: 4 - Parallel Seq Scan on large_table Filter: (status active)只要计划中出现Gather即表示该子树启用了并行。三、关键配置参数详解并行查询的行为由多个 GUC 参数控制按作用域可分为三类3.1 全局资源限制需谨慎调整参数默认值说明max_worker_processes8整个实例允许的最大后台工作进程数包括并行 Worker、逻辑复制等。修改需重启。max_parallel_workers8整个实例允许的最大并行 Worker 总数受max_worker_processes限制。max_parallel_maintenance_workers2用于CREATE INDEX、VACUUM等维护操作的并行 Worker 数。类比max_worker_processes是银行总现金max_parallel_workers是可用于取款的额度。3.2 单查询并行度控制参数默认值说明max_parallel_workers_per_gather2单个Gather节点最多启动的 Worker 数。动态可改SET或ALTER SYSTEM。此参数最常用直接影响单查询的并行能力。3.3 并行决策成本模型优化器通过成本估算决定是否启用并行。以下参数影响决策阈值参数默认值说明parallel_setup_cost1000.0启动并行进程、初始化共享内存的“虚拟成本”。值越大越难触发并行。parallel_tuple_cost0.1每个元组从 Worker 传回 Leader 的通信成本。值越大并行收益越低。min_parallel_table_scan_size8MB表大小 ≥ 此值才考虑并行扫描。每增大 3 倍增加 1 个 Worker。min_parallel_index_scan_size512kB索引大小 ≥ 此值才考虑并行索引扫描。3.4 其他控制参数参数默认值说明force_parallel_modeoff强制开启并行测试用生产禁用。parallel_leader_participationonLeader 是否参与数据扫描关闭可减少 Leader 负载但可能降低效率。四、并行度的确定规则Worker 数量并非简单等于max_parallel_workers_per_gather而是由以下因素共同决定表/索引大小若表大小 min_parallel_table_scan_size不启用并行。否则Worker 数 ≈log3(表大小 / min_parallel_table_scan_size) 1但不超过max_parallel_workers_per_gather。示例min_parallel_table_scan_size 8MB表大小 8MB → 1 Worker24MB → 2 Workers72MB → 3 Workers216MB → 4 Workers系统资源限制实际启动 Worker 数 MIN(规划数,max_parallel_workers_per_gather, 剩余可用max_parallel_workers)表级设置可通过ALTER TABLE ... SET (parallel_workers N)为特定表指定并行度覆盖全局设置。五、并行查询的限制与不支持场景尽管功能强大并行查询仍有诸多限制5.1 查询类型限制不支持写操作INSERT/UPDATE/DELETE/MERGE不支持CURSOR不支持FOR UPDATE/SHARE锁不支持SECURITY LABEL、RULES可序列化Serializable隔离级别下禁用客户端设置fetch_count如 JDBC fetchSize会禁用并行。5.2 算子限制窗口函数Window Functions整体不可并行但部分子表达式可有序集聚合Ordered-set Aggregates如PERCENTILE_CONT不支持CTECommon Table Expressions默认物化且不并行可用MATERIALIZED/NOT MATERIALIZED控制外部数据包装器FDW默认不支持并行需 FDW 自身实现。5.3 函数与表达式限制若 WHERE/HAVING/SELECT 中包含非并行安全函数整个查询无法并行。函数的并行安全性由proparallel字段标记s safe默认r restricted仅在 Leader 安全u unsafe禁用并行可通过pg_proc查看SELECTproname,proparallelFROMpg_procWHEREpronameyour_func;5.4 资源与配置限制所有 CPU 核心已饱和时并行可能恶化性能高work_mem设置会导致内存爆炸每个 Worker 独占work_memI/O 密集型负载未缓存无法从并行中受益。六、性能调优与监控6.1 监控并行执行使用EXPLAIN (ANALYZE, VERBOSE)查看Workers Planned计划 Worker 数Workers Launched实际启动数各 Worker 的执行时间与行数查询活跃 WorkerSELECTpid,backend_type,queryFROMpg_stat_activityWHEREbackend_typeLIKE%parallel%;6.2 调优建议大表 OLAP 查询适当提高max_parallel_workers_per_gather如 4~8高并发 OLTP保持默认或设为 0避免资源争抢内存充足可适度增加work_mem但注意总内存 ≈ max_parallel_workers * work_mem调整成本参数若小表也想并行降低parallel_setup_cost分区表 并行天然契合确保分区剪枝有效。6.3 避免过度并行并行并非总是更快。对于小表或简单过滤启动开销可能超过收益通过对比EXPLAIN ANALYZE关闭/开启并行的结果验证实际效果生产环境建议通过ALTER TABLE ... SET (parallel_workers N)精细控制而非全局调高。七、实战案例7.1 场景分析 10 亿行订单表-- 表结构CREATETABLEorders(id BIGSERIAL,user_idINT,amountNUMERIC,statusTEXT,created_atTIMESTAMP);-- 插入 10 亿行数据略查询统计总金额与订单数EXPLAINANALYZESELECTCOUNT(*),SUM(amount)FROMordersWHEREstatuscompleted;优化步骤确认表足够大 8MB满足并行条件设置并行度SETmax_parallel_workers_per_gather4;执行计划Finalize Aggregate - Gather Workers Planned: 4 - Partial Aggregate - Parallel Seq Scan on orders Filter: (status completed::text)性能对比串行120 秒4 Worker 并行35 秒加速比 ≈ 3.4x注加速比受数据分布、CPU 核数、I/O 带宽等影响通常低于理论值。