SQL 数据库并行查询本质是将大任务拆分为多子任务分发至多核执行后合并结果，能否高效利用多核取决于查询类型、数据分布、优化器决策及配置；仅计算密集或大数据量操作（如全表扫描、大聚合、大排序、哈希 / 归并连接、跨分区查询）可能触发并行，而简单点查、索引覆盖查询等通常走串行。
SQL 数据库的并行查询机制，本质是把一个大查询任务拆成多个子任务，分发到多个 CPU 核心上同时执行，最后合并结果。能否真正用好多核，不只看 CPU 有几个核，更取决于查询类型、数据分布、优化器决策和数据库配置。
哪些查询能触发并行执行
不是所有 SQL 都会并行。通常只有计算密集或扫描量大的操作才可能启用并行，比如：
- 大表全表扫描（尤其是没有高效索引时）
- 聚合运算（COUNT、SUM、AVG 等配合 GROUP BY 且数据量大）
- 大范围排序（ORDER BY + LIMIT 配合大量数据）
- 哈希连接（Hash Join）或归并连接（Merge Join）中的数据重分布阶段
- 分区表上的跨分区查询（尤其当各分区可独立处理时）
简单点查（如 WHERE id = ?）、索引覆盖查询、小结果集 JOIN，优化器通常认为并行开销大于收益，会走串行计划。
数据库如何决定是否并行及用几个线程
决策权在查询优化器，它基于代价模型估算：
- 预估扫描行数、数据大小、内存占用、I/ O 等待时间
- 当前系统负载（如活跃会话数、CPU 就绪队列长度）
- 用户设置的并行度参数（如 PostgreSQL 的red”>max_parallel_workers_per_gather，SQL Server 的MAXDOP）
- 是否启用了并行功能（如 MySQL 8.0+ 默认关闭并行查询，需显式开启）
即使允许并行，实际使用的 worker 数量也可能是动态调整的——例如预估 100 万行，但前 10 万行就命中了 LIMIT 100，后续 worker 可能被快速取消。
常见影响多核利用率的关键配置
光靠硬件不行，得调对参数：
- 并行工作进程上限 ：PostgreSQL 设max_parallel_workers_per_gather=4，表示单个 Gather 节点最多拉起 4 个 worker；SQL Server 用OPTION (MAXDOP 4) 控制单语句最大并行度
- 最小并行阈值 ：PostgreSQL 的parallel_setup_cost 和parallel_tuple_cost影响启动并行的“心理门槛”，调低更容易触发并行
- CPU 亲和与资源隔离：在高并发场景下，可通过 taskset 或 cgroups 绑定数据库进程到特定 CPU 核组，避免调度抖动干扰并行稳定性
- 内存分配策略 ：并行查询需要额外共享内存（如 PostgreSQL 的shared_buffers 和work_mem），若单 worker 内存不足，可能退化为串行或频繁落盘
验证并行是否生效的实用方法
别猜，要看执行计划和运行时指标：
- PostgreSQL：EXPLAIN (ANALYZE, BUFFERS) 输出中看到 Gather 或Gather Merge节点，且子节点标有Workers Launched: 3
- SQL Server：查看执行计划 XML，搜索 Parallelism 或Repartition Streams算子；也可查 sys.dm_exec_query_profiles 实时观察线程级进度
- 性能监控：用 top / htop 观察多核 CPU 使用率是否同步上升；或查 pg_stat_activity 中 backend_type 为 client backend 和parallel worker的会话数
如果计划显示并行但 CPU 利用率仍单核飙升，大概率是 I / O 瓶颈或锁争用导致 worker 空等，不是并行本身失效。
