并行技术对比

并行技术对比

目录

要全面对比 PostgreSQL、MySQL、Oracle 的 “并行” 能力，需先明确核心讨论维度：并行查询（Parallel Query，PQ）（利用多 CPU 核心加速大查询）、并行 DML/DDL（多线程执行数据写入 / 结构变更）、并行复制（主从同步的多线程能力），以及 并行执行的底层机制与适用场景。以下从 “概念对比”“核心能力拆解”“实现案例” 三个层面展开，最终汇总关键差异。

一、核心概念与设计定位

三者对 “并行” 的设计定位差异，源于数据库的诞生背景与目标场景：

  • Oracle：企业级数据库标杆，并行能力从 1990 年代（Oracle 7）开始迭代，专为大规模数据仓库、OLAP 分析场景设计，支持全链路并行（查询、DML、DDL、备份恢复），功能最全面。
  • PostgreSQL：开源数据库中并行能力的 “后起之秀”，从 9.6 版本（2016） 开始支持并行查询，后续版本（10+）逐步扩展到并行 DML/DDL，兼顾 OLTP 与 OLAP，平衡灵活性与性能。
  • MySQL：早期（5.7 及之前）几乎无并行能力，核心定位 OLTP（高并发小事务），从 8.0 版本（2018） 开始有限支持并行查询，且仅针对特定场景（如分区表扫描），并行能力最弱，优先保证事务一致性与轻量并发。

二、三大数据库并行能力对比（核心维度）

1. 并行查询（Parallel Query）

并行查询是 “多 CPU 核心协同处理单个大查询”（如全表扫描、大表 Join、聚合计算），核心解决 “单查询耗时过长” 问题，是 OLAP 场景的关键能力。

维度 Oracle PostgreSQL MySQL
支持版本 Oracle 7+（19c/21c 已高度成熟） 9.6+（基础并行查询），10+（扩展场景），15+（并行哈希 Join 优化） 8.0.14+（仅支持 “并行全表扫描” 和 “并行索引扫描”，且限制多）
核心机制 1. 由 查询协调器（QC） 拆分任务为 “并行执行服务器（PX Server）”；
2. 支持 “生产者 - 消费者” 模型，可跨节点并行（RAC 集群）。		 1. 由 主进程（Leader） 拆分任务为 “工作进程（Worker）”；
2. 基于共享内存通信，仅单机并行（无原生集群并行）。		 1. 由 SQL 执行器 拆分任务为 “并行扫描线程”；
2. 仅支持 InnoDB 引擎，且依赖 “表分区” 或 “大表” 触发。
支持的查询算子 全表扫描、索引扫描、Join（Hash/Nested Loop/Merge）、聚合（GROUP BY）、排序（ORDER BY）、窗口函数、子查询。 全表扫描、索引扫描、Hash Join、聚合（GROUP BY）、排序（LIMIT 前）、部分窗口函数。 仅支持 全表扫描 和 索引范围扫描（如分区表的跨分区扫描），不支持 Join、聚合的并行。
并行度控制 1. 手动指定：PARALLEL 4（语句级）、表级默认并行度；
2. 自动调整：根据 CPU 核心数、负载动态优化。		 1. 手动指定：SET max_parallel_workers_per_gather = 4（会话级）；
2. 全局参数：max_parallel_workers（最大总工作进程数）。		 1. 手动指定：SET innodb_parallel_read_threads = 4（会话级）；
2. 仅控制 “扫描线程数”，无全局并行度限制（易超 CPU）
限制条件 1. 小查询自动禁用（成本低于阈值）；
2. 某些 DDL（如 CREATE TABLE AS SELECT）可并行。		 1. 临时表、物化视图刷新不支持；
2. 事务隔离级别为 “可串行化” 时禁用；
3. 小查询自动禁用（成本估算低于阈值）。		 1. 非分区表仅当 “表大小超过 innodb_parallel_read_threshold”（默认 256MB）才触发；
2. 事务中若有写操作，并行查询自动降级为串行。

2. 并行 DML/DDL（数据写入 / 结构变更）

并行 DML（INSERT/UPDATE/DELETE）和并行 DDL（CREATE TABLE/ALTER TABLE）用于加速 “大批量数据写入” 或 “大表结构变更”，是数据仓库初始化、ETL 的关键能力。

维度 Oracle PostgreSQL MySQL
并行 DML 支持 1. 需显式开启：ALTER SESSION ENABLE PARALLEL DML；
2. 支持 INSERT（含 APPEND）、UPDATE、DELETE、MERGE；
2.3. 可与并行查询结合（如 INSERT ... SELECT 并行）。		 1. 11 + 版本支持并行 INSERT（仅 COPY 命令和 INSERT ... SELECT）；
2.2. 不支持并行 UPDATE/DELETE（仅串行执行）。		 1. 完全不支持并行 DML；
2.2. 即使开启并行查询，DML 操作仍为单线程（如 UPDATE 大表时仅 1 个线程）。
并行 DDL 支持 1. 支持 CREATE TABLE AS SELECT（CTAS）、CREATE INDEX、ALTER TABLE（分区操作）、TRUNCATE、DROP TABLE；
2.2. 索引创建可并行（如CREATE INDEX ... PARALLEL 4）。		 1. 11 + 版本支持并行 CREATE INDEX（B-Tree/GIN 索引）；
2.2. 12 + 版本支持并行 CTAS；
2.3. 不支持 ALTER TABLE、DROP TABLE 的并行。		 1. 完全不支持并行 DDL；
2.2. 即使创建大表索引，也仅单线程（如 CREATE INDEX 需锁表且耗时久）。

3. 并行复制（主从同步）

并行复制解决 “主库高写入时，从库同步延迟” 问题，核心是 “多线程复制主库的 binlog/redo 日志”。

维度 Oracle PostgreSQL MySQL
复制架构 主从复制（Data Guard）、集群复制（RAC） 主从复制（流复制）、逻辑复制（10+） 主从复制（基于 binlog）、组复制（8.0+）
并行复制机制 1. Data Guard：从库 RFS 进程 接收日志，MRP 进程 并行应用（按 “日志组” 拆分）；
2. RAC：基于共享存储，实例间并行读写。		 1. 流复制：从库 walreceiver 接收 WAL 日志，startup 进程串行应用（默认）；
2. 11 + 版本支持 “并行应用”（按 “WAL 记录类型” 拆分，如 DML/DDL 分开）。		 1. 5.7 + 支持 “并行复制”：从库 SQL 线程 拆分为 “多个 worker 线程”，按 “库” 或 “表” 并行应用；
2. 8.0 + 支持 “逻辑时钟并行”（按事务提交顺序并行）。
核心参数 LOG_ARCHIVE_MAX_PROCESSES（RFS 进程数）
PARALLEL_RECOVERY（并行恢复）		 max_wal_senders（主库发送进程数）
max_parallel_workers_per_gather（从库并行应用）		 slave_parallel_workers（从库 worker 线程数）
slave_parallel_type（按库 / 表 / 逻辑时钟）
同步延迟控制 企业级优化，支持 “实时同步（SYNC）” 和 “延迟同步”，并行应用几乎无延迟。 并行应用可降低延迟，但默认串行（适合 OLTP），OLAP 场景需手动开启并行。 逻辑时钟并行可大幅降低延迟，但仍弱于 Oracle，大事务场景仍可能延迟。

三、实现案例（基于相同场景）

以 “1 亿行大表的聚合查询” 为例（表结构：sales(id INT, sale_date DATE, amount NUMERIC, region VARCHAR(50))），对比三者的并行实现。

1. Oracle 案例（并行查询 + 并行索引）

场景：统计 2023 年各区域销售额（需全表聚合，数据量 1 亿行）

-- 1. 为表设置默认并行度（表级）
ALTER TABLE sales PARALLEL 4;

-- 2. 执行并行聚合查询（自动触发并行）
SELECT 
  region, 
  SUM(amount) AS total_sales 
FROM sales 
WHERE sale_date BETWEEN '2023-01-01' AND '2023-12-31' 
GROUP BY region;

-- 3. 查看并行执行计划（确认是否使用并行）
EXPLAIN PLAN FOR
SELECT region, SUM(amount) FROM sales WHERE sale_date BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY region;

-- 执行计划关键信息：
-- "PX COORDINATOR"（查询协调器）
-- "PX SEND QC (RANDOM)"（向协调器发送结果）
-- "PX BLOCK ITERATOR"（拆分表数据块）
-- "HASH GROUP BY"（并行聚合）

并行 DML 案例（批量插入）

-- 1. 开启并行DML
ALTER SESSION ENABLE PARALLEL DML;

-- 2. 并行插入（从大表筛选数据插入新表）
INSERT /*+ PARALLEL(4) APPEND */ INTO sales_2023
SELECT * FROM sales WHERE sale_date BETWEEN '2023-01-01' AND '2023-12-31';

2. PostgreSQL 案例（并行查询 + 并行索引）

场景：同 Oracle，统计 2023 年各区域销售额

查看并行相关参数：
-- 查看并行相关参数
SELECT name, setting, unit, context 
FROM pg_settings 
WHERE name LIKE '%parallel%' 
ORDER BY name;

-- 测试并行查询
EXPLAIN (ANALYZE, VERBOSE)
SELECT COUNT(*) FROM emp WHERE id > 0;

-- 1. 配置并行参数（会话级，4个工作进程）
SET max_parallel_workers_per_gather = 4;
SET max_parallel_workers = 8; -- 全局最大工作进程数（避免资源耗尽）

-- 2. 执行并行聚合查询（自动触发并行）
SELECT 
  region, 
  SUM(amount) AS total_sales 
FROM sales 
WHERE sale_date BETWEEN '2023-01-01' AND '2023-12-31' 
GROUP BY region;

-- 3. 查看并行执行计划（确认worker进程数）
EXPLAIN ANALYZE
SELECT region, SUM(amount) FROM sales WHERE sale_date BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY region;

-- 执行计划关键信息：
-- "Gather  (cost=1000.00..500000.00 rows=100 width=36) (actual time=0.10..1200.00 rows=100 loops=1)"
-- "  Workers Planned: 4"（计划4个worker）
-- "  Workers Launched: 4"（实际启动4个worker）
-- "  ->  Parallel HashAggregate  (cost=0.00..499990.00 rows=25 width=36)"（并行聚合）

并行 DDL 案例（创建索引）

-- 并行创建B-Tree索引（4个worker进程）
CREATE INDEX idx_sales_sale_date ON sales (sale_date) WITH (parallel_workers = 4);

3. MySQL 案例（有限并行查询）

场景：同前，但 MySQL 仅支持并行扫描，聚合仍串行

-- 1. 配置并行扫描参数（会话级，4个线程）
SET innodb_parallel_read_threads = 4;
SET innodb_parallel_read_threshold = 100M; -- 表大小超过100MB触发并行

-- 2. 执行查询（仅扫描阶段并行，聚合阶段串行）
SELECT 
  region, 
  SUM(amount) AS total_sales 
FROM sales 
WHERE sale_date BETWEEN '2023-01-01' AND '2023-12-31' 
GROUP BY region;

-- 3. 查看执行计划（确认是否并行）
EXPLAIN ANALYZE
SELECT region, SUM(amount) FROM sales WHERE sale_date BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY region;

-- 执行计划关键信息（仅并行扫描）：
-- "-> Table scan on sales  (cost=1000000.00 rows=100000000) (actual time=0.00..5000.00 rows=100000000 loops=1)"
-- "  Parallel threads: 4"（4个并行扫描线程）
-- "-> Aggregate: sum(amount)  (cost=1000000.00..1000000.00 rows=100) (actual time=5000.00..6000.00 rows=100 loops=1)"（聚合串行）

限制：MySQL 无并行 DML/DDL
若执行批量插入，即使表很大，仍为单线程：

-- MySQL 批量插入（单线程，无并行）
INSERT INTO sales_2023
SELECT * FROM sales WHERE sale_date BETWEEN '2023-01-01' AND '2023-12-31';

四、关键差异汇总与场景选型

1. 核心差异表

能力 Oracle PostgreSQL MySQL
并行查询成熟度 ★★★★★（全算子支持，集群并行） ★★★★☆（单机并行，核心算子支持） ★☆☆☆☆（仅并行扫描，限制多）
并行 DML/DDL 支持 ★★★★★（全 DML/DDL 并行） ★★★☆☆（部分 DML/DDL 并行） ★☆☆☆☆（无并行 DML/DDL）
并行复制能力 ★★★★★（Data Guard 并行应用，RAC 集群） ★★★☆☆（流复制并行应用，逻辑复制） ★★★☆☆（逻辑时钟并行，组复制）
易用性 ★★★★☆（自动并行，参数少） ★★★☆☆（需手动配置参数，学习成本中等） ★★★☆☆（参数简单，但功能弱）
成本 ★☆☆☆☆（商业授权，成本高） ★★★★★（开源免费，无 license 成本） ★★★★☆（开源免费，企业版有增值服务）

2. 场景选型建议

  • OLAP 分析场景（大查询、大批量数据）：
    • 首选 Oracle：并行能力最强，适合超大规模数据仓库（如金融、电信的 BI 分析）。
    • 次选 PostgreSQL：开源中最优，成本低，适合中小型数据仓库（如电商数据分析）。
    • 避免 MySQL：并行能力有限，大查询耗时久，仅适合简单 OLAP（如小表统计）。
  • OLTP 事务场景（高并发小查询）：
    • 首选 MySQL/PostgreSQL：轻量高效，事务支持成熟，并行复制可降低主从延迟。
    • 次选 Oracle：功能强但资源占用高，适合对稳定性要求极高的核心业务（如银行核心系统）。
  • 混合场景（OLTP+OLAP）：
    • 首选 PostgreSQL：平衡并行查询与事务性能，开源免费，运维成本低。
    • 次选 Oracle：需购买 license，但可通过 “读写分离”（主库 OLTP，从库 OLAP）优化。
    • 避免 MySQL：OLAP 能力弱，无法满足复杂分析需求。

五、总结

三者的并行能力差异本质是 “设计目标的差异”：

  • Oracle 面向企业级复杂场景，并行是 “核心竞争力”；
  • PostgreSQL 面向开源全能场景，并行是 “补齐短板” 后的重要特性；
  • MySQL 面向轻量 OLTP 场景，并行是 “后期补充” 的有限功能。
    实际选型时，需结合 “业务场景（OLTP/OLAP）”“数据规模”“成本预算” 综合判断，而非单纯比较并行能力强弱。
posted @ 2026-05-19 11:05  数据库小白（专注）  阅读(15)  评论(0)    收藏  举报