O operador de junção de hash sempre puxa do lado da compilação?

Se você postar o plano de consulta real para sua consulta específica, poderemos comentar sobre isso mais diretamente.

Mas, em geral, acredito (e sempre observei) que o operador hash join sempre é executado como você esperava:

1. Crie uma tabela de hash do lado da compilação.
2. Combine todas as linhas do probe com ele.

Isso geralmente faz sentido, pois o SQL Server colocará o conjunto de linhas menor (estimado) no lado de compilação da junção. Espera-se que o lado do probe seja maior que o lado da compilação (e, portanto, contenha pelo menos algumas linhas).

Além disso, o SQL Server tem uma potencial otimização de bitmap que pode ser aplicada ao lado de investigação de uma junção de hash em alguns casos, mas essa otimização requer que o lado de compilação seja processado primeiro.

Um exemplo

Para uma consulta simples em que forçamos um lado de compilação grande da junção de hash e um lado de teste vazio, o plano de execução real mostra que todas as linhas são processadas no lado de compilação da junção.

-- 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

O lado de construção pode ser ignorado?

Há pelo menos um exemplo em que o lado de construção da junção de hash pode ser ignorado: Em alguns casos, a junção inteira pode ser eliminada. Por exemplo, aqui o SQL Server é capaz de provar antes da execução que o lado do probe terá 0 linhas. O plano de consulta final é, portanto, uma varredura constante e não há junção de hash.

-- 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

E o modo de lote?

Com base em um teste rápido, parece que o operador de junção de hash do modo de lote também processará totalmente o lado de compilação da junção de hash.

-- 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