Início / dba / Perguntas / 172535
Accepted
John Eisbrener
Asked: 2017-05-03 07:47:13 +0800 CST

Operador escalar no predicado de busca e uma estimativa de linha de 1

  • 772

Estou tentando entender algum comportamento que estou vendo em um plano de consulta que é bastante grande e indisciplinado. Em particular, estou olhando para uma operação de busca de índice clusterizado contendo uma operação escalar dentro de seu predicado. Suspeito que a operação Scalar seja simplesmente o alias de uma das tabelas (conforme descrito em Scalar Operator in Seek Predicate ), pois ambas as colunas são do mesmo tipo e essa operação alimenta um operador de Loops Aninhados Paralelos (Left Outer Join) .

Minha pergunta, porém, é mais sobre a estimativa de linha chegando em 1, em vez de um número mais próximo do número real de linhas (~ 6,7 milhões). A operação escalar está matando a capacidade do otimizador de estimar as linhas corretamente? Eu suponho que sim e também assumo que isso está prejudicando meu plano de execução de consulta de ser ideal, mas eu realmente não tenho certeza. Alguém pode confirmar ou refutar minhas suspeitas junto com o porquê?

Aqui está a operação em questão:

insira a descrição da imagem aqui

Versão: SQL Server 2012 Enterprise

sql-server sql-server-2012

1 respostas

  1. Best Answer

    No lado interno de uma junção de loop aninhado, o número estimado de linhas representa uma estimativa por iteração do loop. O número real de linhas é o número total de linhas retornadas para todas as iterações da junção. Isso não é intuitivo e uma fonte comum de confusão.

    Podemos ver essa ação com uma demonstração simples:

    CREATE TABLE dbo.X_OUTER_TABLE (ID INT NOT NULL);

INSERT INTO dbo.X_OUTER_TABLE WITH (TABLOCK)
SELECT TOP 100 ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values;

CREATE TABLE dbo.X_INNER_TABLE (ID INT NOT NULL, PRIMARY KEY (ID));

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

    Informações detalhadas para a busca de índice clusterizado em X_INNER_TABLE:

    informações do nó

    O número estimado de linhas é 1 porque a busca é executada na chave primária completa da tabela. O número real de linhas é 100 porque a tabela externa tem 100 linhas, o loop itera 100 vezes e 1 linha é encontrada em cada loop.

    Um operador escalar semelhante aparece na demonstração simples conforme você observou em seu plano de consulta. Não há muito o que fazer em sua pergunta original, mas é provável que o escalar seja de fato um arenque vermelho. Em vez disso, eu me concentraria na diferença entre o número estimado de execuções (580308) e o número real de execuções (6740779). O SQL Server estimou que a tabela externa teria 10% das linhas que ela realmente tinha, portanto, o custo do loop aninhado é inapropriadamente baixo. É possível que, se o otimizador tivesse uma estimativa de cardinalidade mais precisa para a tabela externa, ele mudaria de uma junção de loop aninhada nessa tabela para um plano diferente.

    • 3

relate perguntas