Por que o operador de paralelismo (fluxos de partição) reduziria as estimativas de linha para 1?

Os planos de consulta com filtros de bitmap às vezes podem ser difíceis de ler. Do artigo BOL para fluxos de repartição (ênfase minha):

O operador Repartição Streams consome vários fluxos e produz vários fluxos de registros. O conteúdo e o formato do registro não são alterados. Se o otimizador de consulta usar um filtro de bitmap, o número de linhas no fluxo de saída será reduzido.

Além disso, um artigo sobre filtros de bitmap também é útil:

Ao analisar um plano de execução contendo filtragem de bitmap, é importante entender como os dados fluem pelo plano e onde a filtragem é aplicada. O filtro de bitmap e bitmap otimizado são criados no lado da entrada de construção (tabela de dimensão) de uma junção de hash; no entanto, a filtragem real normalmente é feita no operador Parallelism, que está no lado de entrada do probe (a tabela de fatos) da junção de hash. No entanto, quando o filtro de bitmap é baseado em uma coluna inteira, o filtro pode ser aplicado diretamente à tabela inicial ou operação de varredura de índice em vez do operador Paralelismo. Essa técnica é chamada de otimização em linha.

Eu acredito que é isso que você está observando com sua consulta. É possível criar uma demonstração relativamente simples para mostrar um operador de repartição de fluxos reduzindo uma estimativa de cardinalidade, mesmo quando o operador de bitmap está IN_ROWem relação à tabela de fatos. Preparação de dados:

create table outer_tbl (ID BIGINT NOT NULL);

INSERT INTO outer_tbl WITH (TABLOCK)
SELECT TOP (1000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values;

create table inner_tbl_1 (ID BIGINT NULL);
create table inner_tbl_2 (ID BIGINT NULL);

INSERT INTO inner_tbl_1 WITH (TABLOCK)
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) / 2000000 - 2) NUM
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

INSERT INTO inner_tbl_2 WITH (TABLOCK)
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) / 2000000 - 2) NUM
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

Aqui está uma consulta que você não deve executar:

SELECT *
FROM outer_tbl o
INNER JOIN inner_tbl_1 i ON o.ID = i.ID
INNER JOIN inner_tbl_2 i2 ON o.ID = i2.ID
OPTION (HASH JOIN, QUERYTRACEON 9481, QUERYTRACEON 8649);

Eu carreguei o plano . Dê uma olhada no operador perto de inner_tbl_2:

Você também pode achar útil o segundo teste em Hash Joins on Nullable Columns de Paul White.

Existem algumas inconsistências na forma como a redução de linha é aplicada. Só consegui ver em um plano com pelo menos três mesas. No entanto, a redução nas linhas esperadas parece razoável com a distribuição de dados correta. Suponha que a coluna unida na tabela de fatos tenha muitos valores repetidos que não estão presentes na tabela de dimensões. Um filtro de bitmap pode eliminar essas linhas antes que elas atinjam a junção. Para sua consulta, a estimativa é reduzida para 1. Como as linhas são distribuídas entre a função de hash fornece uma boa dica:

Com base nisso, suspeito que você tenha muitos valores repetidos para a Object1.Column21coluna. Se as colunas repetidas não estiverem no histograma de estatísticas , o Object4.Column19SQL Server poderá obter a estimativa de cardinalidade muito errada.

Eu acho que você deve se preocupar, pois pode ser possível melhorar o desempenho da consulta. Obviamente, se a consulta atender aos requisitos de tempo de resposta ou SLA, talvez não valha a pena investigar mais. No entanto, se você deseja investigar mais, há algumas coisas que você pode fazer (além de atualizar as estatísticas) para ter uma ideia se o otimizador de consulta escolheria um plano melhor se tivesse informações melhores. Você pode colocar os resultados da junção entre Database1.Schema1.Object10e Database1.Schema1.Object11em uma tabela temporária e ver se continua a obter junções de loop aninhadas. Você pode alterar essa junção para a LEFT OUTER JOINpara que o otimizador de consulta não reduza o número de linhas nessa etapa. Você pode adicionar uma MAXDOP 1dica à sua consulta para ver o que acontece. Você poderia usarTOPjunto com uma tabela derivada para forçar a junção a ser a última, ou você pode até comentar a junção da consulta. Espero que essas sugestões sejam suficientes para você começar.

Em relação ao item de conexão na pergunta, é extremamente improvável que esteja relacionado à sua pergunta. Esse problema não tem a ver com estimativas de linha ruins. Tem a ver com uma condição de corrida em paralelismo que faz com que muitas linhas sejam processadas no plano de consulta nos bastidores. Aqui parece que sua consulta não está fazendo nenhum trabalho extra.

O problema central aqui é uma estimativa de cardinalidade ruim para o resultado da primeira junção. Isso pode surgir por vários motivos, mas na maioria das vezes são estatísticas desatualizadas ou vários predicados de junção correlacionados, que o modelo padrão do otimizador assume que são independentes.

No último caso, CORREÇÃO: desempenho ruim ao executar uma consulta que contém predicados AND correlacionados no SQL Server 2008 ou no SQL Server 2008 R2 ou no SQL Server 2012 pode ser relevante usando o sinalizador de rastreamento suportado 4137. Você também pode tentar a consulta com sinalizador de rastreamento 4199 para habilitar correções do otimizador e/ou 2301 para habilitar extensões de modelagem. É difícil saber com base em um plano anônimo.

A presença do bitmap não afeta diretamente a estimativa de cardinalidade da junção, mas torna seu efeito visível mais cedo aplicando a redução de semijunção antecipada. Sem o bitmap, a estimativa de cardinalidade para a primeira junção seria a mesma e o restante do plano ainda seria otimizado de acordo.

Se você estiver curioso, em um sistema de teste, você pode desabilitar bitmaps para a consulta com o sinalizador de rastreamento 7498. Você também pode desabilitar bitmaps otimizados (considerados pelo otimizador e afetando as estimativas de cardinalidade), substituindo-os por bitmaps pós-otimização (não considerados pelo otimizador, sem efeito na cardinalidade) com uma combinação dos sinalizadores de rastreamento 7497 e 7498. Nenhum deles é documentado ou suportado para uso em um sistema de produção, mas eles produzem planos que o otimizador poderia considerar normalmente e, portanto, podem ser forçados com um guia de planos.

Nada disso resolverá o problema central da estimativa ruim para a primeira junção, conforme observado acima, então estou apenas mencionando isso por interesse.

Leitura adicional sobre bitmaps e junções de hash:

• Bitmap Magic (ou… como o SQL Server usa filtros de bitmap) por mim
• Parallel Hash Join por Craig Freedman
• Bitmaps de execução de consulta pela equipe de processamento de consulta do SQL Server
• Interpretando planos de execução contendo filtros de bitmap nos manuais online
• Noções básicas sobre junções de hash nos livros on-line

respondeu a você no Twitter. Eu olhei para o XML anexado e vi paralelismo desequilibrado. 1 thread tem quase todas as linhas reais, enquanto a maioria dos outros não. Isso grita paralelismo desequilibrado que está ocorrendo. Portanto, eu examinaria o valor da chave/junção e suas respectivas estatísticas e cardinalidade.

De acordo com sua outra ideia, não tenho tanta certeza de que o item Connect se aplique, pois seu plano colado não contém TOP em nenhum lugar que eu vi.