Digamos, temos uma consulta como esta:
select a.*,b.*
from
a join b
on a.col1=b.col1
and len(a.col1)=10
Supondo que a consulta acima use um Hash Join e tenha um residual, a chave de investigação será col1
e o residual será len(a.col1)=10
.
Mas ao passar por outro exemplo, pude ver que tanto a sonda quanto o residual são a mesma coluna. Abaixo está uma elaboração sobre o que estou tentando dizer:
Consulta:
select *
from T1 join T2 on T1.a = T2.a
Plano de execução, com sonda e residual em destaque:
Dados de teste:
create table T1 (a int, b int, x char(200))
create table T2 (a int, b int, x char(200))
set nocount on
declare @i int
set @i = 0
while @i < 1000
begin
insert T1 values (@i * 2, @i * 5, @i)
set @i = @i + 1
end
declare @i int
set @i = 0
while @i < 10000
begin
insert T2 values (@i * 3, @i * 7, @i)
set @i = @i + 1
end
Pergunta:
Como uma sonda e um resíduo podem ser a mesma coluna? Por que o SQL Server não pode usar apenas a coluna do probe? Por que ele precisa usar a mesma coluna como residual para filtrar as linhas novamente?
Referências para dados de teste:
Se a junção estiver em uma única coluna digitada como
tinyint
,smallint
, ouinteger
* e se ambas as colunas forem restritas aNOT NULL
, a função de hash será 'perfeita' - significando que não há chance de uma colisão de hash e o processador de consulta não precisa verificar os valores novamente para garantir que eles realmente correspondam.Caso contrário, você verá um resíduo à medida que os itens no bucket de hash são testados para uma correspondência, não apenas uma correspondência de função de hash.
Seu teste não especifica
NULL
ouNOT NULL
para as colunas (uma prática ruim, por sinal), então parece que você está usando um banco de dados ondeNULL
é o padrão.Mais informações no meu post Join Performance, Implicit Conversions, and Residuals and Hash Join Execution Internals por Dmitry Pilugin.
* Outros tipos de qualificação são bit , smalldatetime , smallmoney e (var)char(n) para n = 1 e agrupamento binário