Por que a variável da tabela está forçando uma varredura de índice enquanto a tabela temporária usa pesquisa de busca e marcador?

Question

Estou tentando entender por que o uso de uma variável de tabela está impedindo o otimizador de usar uma busca de índice e, em seguida, uma pesquisa de marcador em vez de uma varredura de índice.

Preenchendo a tabela:

CREATE TABLE dbo.Test 
(
    RowKey INT NOT NULL PRIMARY KEY, 
    SecondColumn CHAR(1) NOT NULL DEFAULT 'x',
    ForeignKey INT NOT NULL 
) 

INSERT dbo.Test 
(
    RowKey, 
    ForeignKey
) 
SELECT TOP 1000000 
    ROW_NUMBER() OVER (ORDER BY (SELECT 0)),
    ABS(CHECKSUM(NEWID()) % 10)     
FROM sys.all_objects s1
CROSS JOIN sys.all_objects s2 

CREATE INDEX ix_Test_1 ON dbo.Test (ForeignKey) 

Preencha uma variável de tabela com um único registro e tente pesquisar a chave primária e a segunda coluna pesquisando na coluna da chave estrangeira:

DECLARE @Keys TABLE (RowKey INT NOT NULL) 

INSERT @Keys (RowKey) VALUES (10)

SELECT 
    t.RowKey,
    t.SecondColumn
FROM
    dbo.Test t 
INNER JOIN 
    @Keys k
ON
    t.ForeignKey = k.RowKey

Abaixo está o plano de execução:

Agora, a mesma consulta usando uma tabela temporária:

CREATE TABLE #Keys (RowKey INT NOT NULL) 

INSERT #Keys (RowKey) VALUES (10) 

SELECT 
    t.RowKey,
    t.SecondColumn
FROM
    dbo.Test t 
INNER JOIN 
    #Keys k
ON
    t.ForeignKey = k.RowKey

Este plano de consulta usa uma pesquisa de busca e marcador:

Por que o otimizador deseja fazer a pesquisa de favoritos com a tabela temporária, mas não com a variável da tabela?

A variável de tabela é usada neste exemplo para representar dados provenientes de um tipo de tabela definido pelo usuário em um procedimento armazenado.

Sei que a busca do índice pode não ser apropriada se o valor da chave estrangeira ocorrer centenas de milhares de vezes.Nesse caso, uma varredura provavelmente seria uma escolha melhor.Para o cenário que criei, não havia nenhuma linha com valor 10.Ainda acho o comportamento interessante e gostaria de saber se há um motivo para isso.

SQL violino

Adicionando OPTION (RECOMPILE) não mudou o comportamento.O UDDT possui uma chave primária.

@@VERSION é SQL Server 2008 R2 (SP2) - 10.50.4042.0 (X64) (Compilação 7601:Service Pack 1) (hipervisor)

Answer 1

A razão para o comportamento é que o SQL Server não pode determinar quantas linhas corresponderão a ForeignKey, uma vez que não há índice com RowKey como coluna principal (ele pode deduzir isso a partir de estatísticas na tabela #temp, mas essas não o fazem). existem para variáveis ​​de tabela/UDTTs), portanto, ele faz uma estimativa de 100.000 linhas, o que é melhor tratado com uma varredura do que com uma busca+pesquisa.Quando o SQL Server perceber que há apenas uma linha, será tarde demais.

Você pode construir seu UDTT de maneira diferente;em versões mais modernas do SQL Server é possível criar índices secundários em variáveis ​​de tabela, mas essa sintaxe não está disponível no 2008 R2.

A propósito, você pode obter o comportamento de busca (pelo menos em meus testes limitados) se tentar evitar o bitmap/sonda sugerindo uma junção de loops aninhados:

DECLARE @Keys TABLE (RowKey INT PRIMARY KEY); -- can't hurt

INSERT @Keys (RowKey) VALUES (10);

SELECT 
     t.RowKey
    ,t.SecondColumn
FROM
    dbo.Test t 
INNER JOIN 
    @Keys k
ON
    t.ForeignKey = k.RowKey
    OPTION (LOOP JOIN);

EU aprendi esse truque com Paul White vários anos atrás.Claro, você deve ter cuidado ao colocar qualquer tipo de dica de junção no código de produção - isso pode falhar se as pessoas fizerem alterações nos objetos subjacentes e esse tipo específico de junção não for mais possível ou não for mais ideal.

Para consultas mais complexas e ao migrar para o SQL Server 2012 ou superior, é possível que sinalizador de rastreamento 2453 Poderia ajudar.Esse sinalizador não ajudou nessa junção simples.E as mesmas isenções de responsabilidade se aplicariam - isso é apenas uma alternativa que você geralmente não deveria fazer sem uma tonelada de documentação e procedimentos rigorosos de teste de regressão em vigor.

Além disso, o Service Pack 1 está sem suporte há muito tempo, você deve entrar em contato Pacote de serviços 3 + MS15-058.

Answer 2

Variáveis ​​de tabela e tabelas temporárias são tratadas de maneira diferente de diversas maneiras.Existe um ótima resposta aqui com muitos detalhes sobre onde eles são diferentes.

Especificamente no seu caso, eu acho que o fato de que as tabelas temporárias podem ter estatísticas adicionais geradas e planos paralelos, enquanto as variáveis ​​da tabela têm estatísticas mais limitadas (sem estatísticas no nível da coluna) e nenhum plano paralelo é o seu culpado.

Talvez seja melhor despejar a variável da tabela em uma tabela temporária durante o procedimento armazenado.