并行度设置必须与集群实际可用核数对齐，否则再好的SQL也会被无效调度拖垮，核心原则是让每个执行单元稳定分到1-2个vCPU，而非盲目追求大数字。
很多团队在调优查询时，第一反应是把并行度调大，看到任务队列里几十个线程同时跑，感觉速度应该翻倍，结果CPU使用率飙到90%以上，查询却比原来还慢，原因很简单：并行度超过核数，线程切换开销就会反噬性能，这个问题在Doris、ClickHouse、SparkSQL、Flink等引擎里普遍存在,只是参数名不同。
并行度和核数错配，慢在哪些看不见的地方
先看一个典型场景，某数据团队用ClickHouse做报表查询，节点配置是16核64G内存，并行度参数却被调成了32，跑一个中等复杂度的聚合查询，实际耗时反而比默认配置慢了接近40%，打开监控面板，CPU的iowait不高，但上下文切换次数高得离谱，每个线程都在抢CPU时间片,谁都没法连续执行。
并行度高于核数时,系统要做三件额外的事：
- 线程频繁挂起和唤醒，一个查询任务被拆成多个子任务，每个子任务跑一小段就被迫让出CPU，等下次调度,这个切换过程本身消耗CPU周期。
- CPU缓存命中率下降，线程切换后，新线程要重新加载数据到L1/L2缓存，原来的缓存数据全部作废，并行度越高,缓存失效越频繁。
- 内存带宽被争抢，多个线程同时读取不同数据块，内存控制器疲于应付,导致整体吞吐下降。
反过来，并行度低于核数时，CPU资源闲置，查询自然快不了。行业共识认为，并行度与核数的比例在1:1到2:1之间是安全区间，超过2倍后，性能收益急剧衰减,甚至出现负优化。
并行度设置怎么匹配集群核数
这里有个关键认知：集群核数不是指机器总核数，而是查询可用的实际核数，如果一台机器跑了多个服务，或者集群中其他任务占用了资源,并行度就要按剩余资源算。
具体操作分四步：
- 确认每个节点的物理核数和超线程状态，登录服务器执行
lscpu，看
CPU(s)
Core(s) per socket，如果启用了超线程，逻辑核数翻倍，但并行度不建议直接按逻辑核数设置，留出20%的余量更稳妥。 - 估算查询可占用的核数比例，生产环境通常有其他任务并行，用总核数减去常驻任务预估占用，再乘以一个安全系数（0.7到0.8比较常见）。
- 根据查询类型微调，纯扫描型查询适合接近1:1的比例，复杂Join或聚合查询可以适度提高并行度,因为这类查询的算子之间常有等待间隙。
- 压测验证，用生产环境的典型SQL，在不同并行度下跑3到5次，取平均值，记录CPU使用率和响应时间的变化曲线,找到拐点。
业内专家指出，很多调优事故都源于把“最大并行度”当成“推荐并行度”，Spark里的spark.sql.shuffle.partitions默认是200，但如果你只有几十个核，这个默认值就会导致每个任务处理的数据量过小,调度开销反而成了大头。
每个执行单元分到多少数据才算均衡
并行度匹配核数只是第一步，数据分配均衡同样重要，假设集群有24个核，你设置了24个并行度，但数据倾斜导致一个任务要处理50%的数据，另外23个任务干等,整体耗时还是由最慢的任务决定。
解决思路有两条：
- 在SQL层面做预聚合或加随机盐,让热点Key分散到不同任务。
- 在引擎层面开启自适应查询执行，比如Spark 3.0以上的AQE，会自动合并小分区、倾斜Join拆分,实际效果比手动调并行度更稳定。
还有一种常见情况：并行度设对了，但单核处理的数据量过大，比如每个任务要扫描几个GB的数据，这会让GC压力变大，此时不要盲目提高并行度，而是考虑增加节点，或者优化存储格式（列式压缩、分区裁剪）。
主流引擎并行度参数调优对比
不同引擎的并行度控制方式差异很大,用错参数名是新手最常见的坑。
| 引擎 | 核心参数 | 默认行为 | 调优建议 |
|---|---|---|---|
| Doris | parallel_fragment_exec_instance_num
|
单实例执行 | 按BE节点核数的50%-70%设置 |
| ClickHouse | max_threads |
自动按核数设置 | 压测后手动固定，避免自动判断失误 |
| SparkSQL | spark.sql.shuffle.partitions |
200 | 按总核数×2~3设置，再结合AQE动态调整 |
| Flink | taskmanager.numberOfTaskSlots |
1 | 与CPU核数比例1:1，上限不超过物理核数 |
以Doris为例，很多用户在集群核数增加后，只加了节点但没动parallel_fragment_exec_instance_num，结果新节点闲置。这个参数的设置逻辑是：并行度 = BE节点核数 × 0.6左右，比如单节点16核，三节点集群总共48核，并行度设置在24到30之间，效果最好，超过36后,性能提升几乎停滞。
ClickHouse有点特殊，它的max_threads是单查询级别的参数，如果集群同时跑多个查询，每个查询都按核数设置，整体并行度就会翻倍，这种情况下，要结合concurrent_threads_soft_limit_num来控制总线程数。
SparkSQL的并行度调优更依赖数据量，行业里有一个粗略估算方式：每个分区的数据量控制在128MB到256MB之间，假设要处理1TB数据，目标分区数在4096到8192之间，再根据集群核数（比如100核）微调,取两者交集偏小值。
SQL查询并行度调优的常见误区
并行度翻倍，性能就翻倍，事实是CPU密集型查询在并行度超过核数后，性能曲线快速下滑，I/O密集型查询的容忍度高一些,但也不是线性增长。
只调并行度，不管内存，并行度提高后，每个线程占用的内存叠加，很容易触发OOM，尤其是Join操作，广播变量和中间结果集都会膨胀，建议在调并行度的同时，检查executor.memory或max_memory_usage,保持比例协调。
拿总核数当可用核数，一台物理机上有16个核，但虚拟机只分配了8核，或者容器限制了CPU份额，用nproc命令查看的是当前环境可见的核数，但还要检查cgroup限制，Docker容器里经常出现nproc显示宿主机核数的问题,这时候必须以实际配额为准。
什么情况下并行度要，故意设得比核数低
有一种反直觉的场景：并行度故意低于核数，整体性能反而更好，典型是大量小查询并发场景，比如前端Dashboard同时触发几十个轻量级聚合查询，每个查询如果各自占用8个线程，总量就爆炸了，此时应该限制单查询并行度为2或4，让更多查询能同时运行,整体吞吐量提升明显。
另一种情况是内存压力大的集群，并行度越高，内存消耗越大，可能触发频繁的垃圾回收或数据落盘，这时候适当降低并行度，用时间换空间,换取更稳定的服务响应。
并行度匹配核数不是机械地设置一个数字，而是要观察集群资源的实时水位，推荐用Grafana或Prometheus监控CPU使用率、线程切换速率、内存占用三个指标，如果CPU使用率长期低于60%，可以尝试提高并行度或增加查询并发；如果CPU经常打满且查询延迟高，先降并行度,再查SQL本身的问题。
Q&A：并行度调优和集群核数匹配常见问题
并行度设置完要不要重启集群？
大多数引擎支持在线修改，Doris通过SET variable方式修改session级或global级参数，立即生效，ClickHouse的max_threads可以在查询级别加SETTINGS前缀，不用重启，Spark则通过提交参数在每次任务时调整,重启成本更低。
为什么我按核数设置了并行度，查询还是很慢？
先检查是否真的用到了全部核数，在Doris里执行SHOW BACKENDS看每个BE节点的CPU使用率，如果某个节点使用率明显偏低，大概率是数据分布不均，再检查是否有其他任务抢占了资源,集群共享环境下的并行度必须动态调整。
并行度和分区数是不是一回事？
不是，分区数决定数据如何切分，并行度决定一次有多少个任务同时运行，如果并行度大于分区数，部分线程会空转；如果分区数远大于并行度，每个线程要串行处理多个分区，调度开销增加，两者需要配合调整，先定分区数，再按核数设置并行度，保证并行度≤分区数。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/638313.html
