Limitações do otimizador com índices filtrados

CREATE TABLE dbo.TableA( pk integer IDENTITY PRIMARY KEY, data bigint SPARSE NULL, padding binary(250) NOT NULL DEFAULT 0x); CREATE TABLE dbo.TableB( pk integer IDENTITY PRIMARY KEY, data bigint SPARSE NULL, padding binary(250) NOT NULL DEFAULT 0x);

-- Números 1 - 2.000INSERT dbo.TableA WITH (TABLOCKX) (data)SELECT TOP (2000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))FROM sys.columns AS cCROSS JOIN sys.columns AS c2ORDER BY ROW_NUMBER() OVER (ORDER BY (SELECT NULL)); -- NULLsINSERT TOP (40000) dbo.TableA WITH (TABLOCKX) (data)SELECT CONVERT(bigint, NULL)FROM sys.columns AS cCROSS JOIN sys.columns AS c2; -- Copiar para TableBINSERT dbo.TableB WITH (TABLOCKX) (data)SELECT ta.dataFROM dbo.TableA AS ta;

CRIAR ÍNDICE NÃO CLUSTERADO ÚNICO uqAON dbo.TableA (dados) WHERE data NOT NULL; CRIAR ÍNDICE NÃO CLUSTERADO ÚNICO uqBON dbo.TableB (data) WHERE data NOT NULL;

DBCC SHOW_STATISTICS (TabelaA, uqA) WITH STAT_HEADER;DBCC SHOW_STATISTICS (TabelaB, uqB) WITH STAT_HEADER;

Exemplo de consulta

SELECT ta.data, tb.dataFROM dbo.TableA AS taJOIN dbo.TableB AS tb ON ta.data =tb.data;

Plano de execução padrão

Adicionando um predicado NOT NULL

SELECT ta.data, tb.dataFROM dbo.TableA AS taJOIN dbo.TableB AS tb ON ta.data =tb.data AND ta.data IS NOT NULL;

Adicionando dois predicados NOT NULL

SELECT ta.data, tb.dataFROM dbo.TableA AS taJOIN dbo.TableB AS tb ON ta.data =tb.data AND ta.data IS NOT NULL AND tb.data IS NOT NULL;

Ainda não é perfeito

1. A entrada pré-ordenada não está disponível
2. A entrada de compilação de hash é menor que a entrada de sonda
3. A entrada da sonda é muito grande

SELECT ta.data, tb.dataFROM dbo.TableA AS taJOIN dbo.TableB AS tb ON ta.data =tb.data AND ta.data IS NOT NULL AND tb.data IS NOT NULLOPTION (MERGE JOIN); 
 A forma do plano é como esperávamos: 
 
  
 
 Uma varredura ordenada de ambos os índices filtrados, ótimas estimativas de cardinalidade, fantástica. Apenas um pequeno problema:este plano de execução é muito pior; o custo estimado saltou de 0,0772056 para 0,741527 . O motivo do salto no custo estimado é revelado verificando as propriedades do operador de junção de mesclagem: 
 
  
 
 Esta é uma junção cara para muitos, onde o mecanismo de execução deve acompanhar as duplicatas da entrada externa em uma tabela de trabalho e retroceder conforme necessário. Duplicatas? Estamos digitalizando um índice exclusivo! Acontece que o otimizador não sabe que um índice exclusivo filtrado produz valores exclusivos (conecte item aqui). Na verdade, esta é uma junção um-para-um, mas o otimizador custa como se fosse muitos-para-muitos, explicando por que ele prefere o plano de junção de hash. 
 
Uma estratégia alternativa
 
 Parece que continuamos enfrentando limitações do otimizador ao usar índices filtrados aqui (apesar de ser um caso de uso destacado nos Manuais Online). O que acontece se tentarmos usar visualizações? 
 
Usando visualizações
 
 As duas visualizações a seguir apenas filtram as tabelas base para mostrar as linhas em que a coluna de dados é NOT NULL : 
 
CREATE VIEW dbo.VAWITH SCHEMABINDING ASSELECT pk, data, paddingFROM dbo.TableAWHERE data IS NOT NULL;GOCREATE VIEW dbo.VBWITH SCHEMABINDING ASSELECT pk, data, paddingFROM dbo.TableBWHERE data IS NOT NULL;
 
 Reescrever a consulta original para usar as visualizações é trivial: 
 
SELECT v.data, v2.dataFROM dbo.VA AS vJOIN dbo.VB AS v2 ON v.data =v2.data;
 
 Lembre-se de que esta consulta produziu originalmente um plano de loops aninhados paralelos com custo de 7,7768 unidades. Com as referências de visualização, obtemos este plano de execução: 
 
  
 
 Este é exatamente o mesmo plano de junção de hash que tivemos que adicionar redundante NOT NULL predicados para obter com os índices filtrados (o custo é 0,0772056 unidades como antes). Isso é esperado, porque tudo o que fizemos essencialmente aqui é enviar o extra NOT NULL predicados da consulta para uma visualização. 
 
Indexando as visualizações
 
 Também podemos tentar materializar as visualizações criando um índice clusterizado exclusivo na coluna pk: 
 
CRIAR ÍNDICE AGRUPADO ÚNICO cuq EM dbo.VA (pk);CRIAR ÍNDICE AGRUPADO ÚNICO cuq EM dbo.VB (pk);
 
 Agora podemos adicionar índices não clusterizados exclusivos na coluna de dados filtrados na exibição indexada: 
 
CRIAR ÍNDICE NÃO CLUSTERADO EXCLUSIVO ix EM dbo.VA (dados); CRIAR ÍNDICE NÃO CLUSTRADO ÚNICO ix EM dbo.VB (dados);
 
 Observe que a filtragem é realizada na exibição, esses índices não clusterizados não são filtrados. 
 
O plano perfeito
 
 Agora estamos prontos para executar nossa consulta na visualização, usando o NOEXPAND dica de tabela: 
 
SELECT v.data, v2.dataFROM dbo.VA AS v WITH (NOEXPAND)JOIN dbo.VB AS v2 WITH (NOEXPAND) ON v.data =v2.data;
 
 O plano de execução é: 
 
  
 
  
 
 O otimizador pode ver o não filtrado índices de exibição não clusterizados são exclusivos, portanto, uma junção de mesclagem de muitos para muitos não é necessária. Este plano de execução final tem um custo estimado de 0,0310929 unidades – ainda menor que o plano de junção de hash (0,0772056 unidades). Isso valida nossa expectativa de que uma junção de mesclagem deve ter o menor custo estimado para essa consulta e conjunto de dados de amostra. 
 
 O NOEXPAND dicas são necessárias mesmo na Enterprise Edition para garantir que a garantia de exclusividade fornecida pelos índices de exibição seja usada pelo otimizador. 
 
Resumo
 
 Esta postagem destaca duas importantes limitações do otimizador com índices filtrados: 
 
 
Predicados de junção redundantes podem ser necessários para corresponder a índices filtrados 
 
Os índices exclusivos filtrados não fornecem informações de exclusividade ao otimizador 
 
 
 Em alguns casos, pode ser prático simplesmente adicionar os predicados redundantes a cada consulta. A alternativa é encapsular os predicados implícitos desejados em uma visão não indexada. O plano de correspondência de hash neste post foi muito melhor do que o plano padrão, mesmo que o otimizador possa encontrar o plano de junção de mesclagem um pouco melhor. Às vezes, você pode precisar indexar a visualização e usar NOEXPAND dicas (necessárias de qualquer maneira para instâncias do Standard Edition). Ainda em outras circunstâncias, nenhuma dessas abordagens será adequada. Desculpe por isso :)