为何预估成本32的SQL查询在并行阈值50时仍并行执行？

核心原因分析 #

1. 排序操作的并行决策特殊逻辑 #

SQL Server里的排序（Sort）运算符，其并行计划的选择逻辑并不完全受Cost Threshold for Parallelism（并行成本阈值）的约束。当优化器判断串行排序会因为内存不足，不得不依赖tempdb进行磁盘排序，进而导致性能暴跌时，哪怕查询的整体预估成本低于阈值，也会选择并行执行来提升排序效率。

你的场景里，100万条数据的排序操作，虽然预估CPU成本只有32，但优化器评估后认为，串行排序的实际开销（尤其是磁盘IO带来的额外成本）远高于并行排序，因此触发了并行计划。

2. 预估成本的计算范围限制 #

Cost Threshold for Parallelism针对的是查询的整体预估CPU成本，但排序操作的并行决策还会结合数据量、内存授予情况等额外因素。比如当排序的行数较大时，优化器会优先考虑用并行排序来缩短执行时间，不会只盯着预设的成本阈值。

3. 新版本SQL Server的行为特性 #

在SQL Server 2019及2022版本中，优化器对并行计划的选择逻辑做了调整，针对大型数据集的排序、聚合等操作，会更倾向于选择并行计划来规避串行执行的性能瓶颈，哪怕成本没达到阈值。

验证思路 #

可以通过以下方式验证上述逻辑：

• 减少表中数据量（比如改为10万行），重新执行查询，此时排序数据量小，优化器会选择串行计划。
• 查看查询计划的内存授予信息，如果串行计划的内存配额不足以完成内存排序，优化器会自动切换到并行计划。

内容的提问来源于stack exchange，提问作者Bart