为什么在这个非常基本的查询中使用哈希匹配运算符

Question

我开始学习一些关于查看执行计划和提高查询效率的知识

考虑这两个基本查询

select distinct pat_id, drug_class, drug_name from rx 

select pat_id, drug_class, drug_name from rx 

以及他们的执行计划

使用的索引：

CREATE CLUSTERED INDEX [ix_overlap] ON [dbo].[rx] 
(
    [pat_id] ASC,
    [fill_date] ASC,
    [script_end_date] ASC,
    [drug_name] ASC
)

即使第一个查询的成本高出 4:1，它的运行速度也比第二个快。为什么向查询添加一个简单的 distinct 会添加（我认为总是不好的，欢迎更正）哈希匹配运算符？如果它运行得更快，为什么它相对于第二个查询具有更高的查询成本。

Answer 1

第一个查询使用并行计划，这意味着“工作”被拆分为由多个线程执行的多个任务。因此，累积 CPU 时间高于用于第二个查询的串行计划。

至于distinct为什么会导致hash匹配运算符出现在计划中；需要聚合或排序操作来确定DISTINCT结果。@SQL_Kiwi可能很快就会弹出更深入的解释，但哈希匹配运算符显然更适合更大的结果集。

优化器倾向于在较大的行集上更喜欢散列匹配聚合，组较少，没有理由生成排序的输出，并且传入的行未按 DISTINCT 表达式排序。较大的输入有利于哈希匹配，因为该算法通常可以很好地扩展（尽管它确实需要内存授权）并且可以很好地利用并行性。更少的组更适合散列，因为这意味着哈希表中的条目更少，并且存储唯一值所需的内存与组的数量（以及组的大小）成正比。哈希匹配不需要或保留传入行流的顺序。[来源]