散列连接运算符是否总是从构建端拉取？

如果您发布特定查询的实际查询计划，我们也许可以更直接地对此发表评论。

但总的来说，我相信（并且一直观察到）散列连接运算符确实总是按您预期的方式运行：

1. 创建构建端哈希表。
2. 将所有探测行与其匹配。

这通常是有意义的，因为 SQL Server 会将较小的（估计的）行集放在连接的构建端。探测端预计比构建端大（因此至少包含一些行）。

此外，SQL Server 有一个潜在的位图优化，它可以在某些情况下应用于散列连接的探测端，但此优化要求首先处理构建端。

一个例子

对于一个简单的查询，我们强制在散列连接的大型构建端和一个空的探测端，实际执行计划显示所有行都在连接的构建端处理。

-- Fully processes the build side of the hash join
SELECT SUM(b.number*p.number) AS meaningless
FROM (
    SELECT 1.0 * v1.number * v2.number AS number
    FROM master..spt_values v1
    CROSS JOIN master..spt_values v2
) b
INNER HASH JOIN (
    SELECT v3.number
    FROM master..spt_values v3
    WHERE number < -100000
) p
    ON p.number = b.number

可以跳过构建端吗？

至少有一个示例可以跳过散列连接的构建端：在某些情况下，可以消除整个连接。例如，这里 SQL Server 能够在执行之前证明探测端将有 0 行。因此最终的查询计划是一个持续的扫描，没有散列连接。

-- No hash join at all; the query optimizer realizes no rows are guaranteed
SELECT SUM(b.number*p.number) AS meaningless
FROM (
    SELECT 1.0 * v1.number * v2.number AS number
    FROM master..spt_values v1
    CROSS JOIN master..spt_values v2
) b
INNER HASH JOIN (
    SELECT v3.number
    FROM master..spt_values v3
    WHERE 0=1
) p
    ON p.number = b.number

批处理模式呢？

基于快速测试，批处理模式散列连接运算符似乎也将完全处理散列连接的构建端。

-- The batch mode hash join also fully processes the build side
-- even if there are 0 rows on the probe side
SELECT number
INTO #spt_values
FROM master..spt_values
GO
CREATE CLUSTERED COLUMNSTORE INDEX CCI_#spt_values ON #spt_values
GO
SELECT SUM(b.number*p.number) AS meaningless
FROM (
    SELECT 1.0 * v1.number * v2.number AS number
    FROM #spt_values v1
    CROSS JOIN #spt_values v2
) b
INNER HASH JOIN (
    SELECT v3.number
    FROM #spt_values v3
    WHERE number < -100000
) p
    ON p.number = b.number
GO