SQL数据库并行执行模型通过数据分区（哈希/范围/复制）与算子级并行（Scan/Join/Aggregate）实现高效并发，依赖分区感知优化器生成合理执行计划，并由执行引擎协调资源、处理容错与全局归并。
SQL数据库中的算子并行拆分与分区执行模型，核心是把一个查询任务按数据或计算逻辑切分成多个可独立、并发执行的子任务，再在多核、多节点环境下调度运行，从而提升整体执行效率。关键不在于“能不能并行”，而在于“怎么切得合理、调度得高效、结果能正确合并”。
按数据分区（Data Partitioning）驱动算子并行
这是最常见也最有效的并行基础。数据库将大表按某种策略（如哈希、范围、列表）物理划分为多个互不重叠的数据分区，每个分区可被单独加载和处理。
- 哈希分区：对连接键或分组键做哈希，把相关数据尽量落到同一分区，减少跨节点数据传输，适合等值连接和GROUP BY场景。
- 范围分区：按时间、ID等有序字段切分，利于范围扫描和排序合并，但容易导致数据倾斜（如某个月数据暴增）。
- 复制分区（Broadcast）：小表全量复制到每个计算节点，避免其参与 shuffle，常用于维表关联（如广播JOIN）。
算子级并行化（Intra-Operator Parallelism）
单个逻辑算子（如Scan、Filter、HashJoin、Sort、Aggregate）内部可拆成多个并行实例，各自处理一部分分区数据。
- 并行Scan：每个分区由独立线程/进程扫描，无锁或轻量锁访问；需注意文件系统IO能力是否匹配并发度。
- 并行HashJoin：构建端（Build）和探测端（Probe）均按相同哈希函数分区，保证同键数据落在同一子任务中；若分区不一致，需先重分布（Repartition）。
- 并行Aggregate：通常采用两阶段聚合：第一阶段各分区本地聚合（Partial Aggregate），第二阶段合并中间结果（Merge Aggregate），降低网络开销。
执行计划的分区感知优化
优化器必须理解底层数据分布，才能生成真正可并行的计划。否则容易出现“逻辑并行、物理串行”或“过度shuffle”等问题。
- 统计信息要包含各分区的行数、值分布、NDV（不同值数量），否则优化器可能误判倾斜风险。
- 谓词下推需考虑分区裁剪（Partition Pruning）：例如WHERE dt = '2024-01-01'应直接跳过其他日期分区，而非全表扫描后再过滤。
- Join顺序与分发策略需协同：若两张表都按user_id哈希分区，且join条件为ON a.user_id = b.user_id，就可避免shuffle，实现分区对齐Join（Partition-Aware Join）。
资源协调与结果归并
并行执行不是简单起一堆线程，还需解决同步、容错和最终结果一致性问题。
- 执行引擎（如Spark SQL、Presto、Greenplum）通过调度器分配task到worker，用DAG或pipeline方式编排依赖关系。
- 中间结果可落盘（spill to disk）或内存直传（pipelined execution），取决于数据量与内存预算。
- 归并阶段需保证全局语义：如ORDER BY需所有分区排序后做多路归并；窗口函数需跨分区重分区以满足frame定义。
