Início / dba / Perguntas / 316480
Accepted
SEarle1986
Asked: 2022-09-06 08:24:05 +0800 CST

Por que uma pesquisa de desigualdade em uma coluna indexada fornece varreduras constantes

  • 772

Usando o banco de dados StackOverflow2010, posso criar um índice na tabela de usuários da seguinte forma:

CREATE INDEX IX_DisplayName ON dbo.Users
(
    DisplayName,
    UpVotes
)

E, em seguida, execute uma pesquisa de desigualdade na chave do índice:

SELECT  DisplayName,
        UpVotes
FROM    Users
WHERE   DisplayName <> N'Alex'

eu pego o plano aqui

Estou tentando descobrir como o SQL Server conseguiu obter os resultados dessa consulta.

O plano começa com algumas varreduras constantes, mas a lista de saída está em branco, então não está claro para mim para que servem.

Cada varredura constante então entra em um escalar de computação, cada uma das quais saída

Compute Scalar Node6
Expr1002 = 10
Expr1003 = NULL
Expr1004 = N'Alex'

Compute Scalar Node9 
Expr1005 = 6 
Expr1006 = N'Alex' 
Expr1007 = NULL

o operador concatenar então parece concatenar algumas das saídas acima:

Expr1010 = Expr1008,Expr1006
Expr1011 = Expr1004,Expr1009
Expr1012 = Expr1002,Expr1005

Mas tem entradas que não consigo ver em nenhum lugar do plano (Expr 1008 e Expr1009)

Também não sei por que a classificação TOP N é necessária

A busca do Índice faz sentido - ela está procurando por > Expr1011 e < Expr1012. Eu diria que isso é basicamente algo como

>= 'a' AND < 'Alex'

ou

> 'Alex' AND <= 'zzzzzzzzzzzzzz'

ou similar.

Alguém pode me explicar passo a passo, como está funcionando esse plano e como posso entender os valores de Expr1011 e Expr1012 (usados ​​na busca do índice) que são produzidos pelo operador de concatenação

sql-server query-performance

1 respostas

  1. Best Answer

    Isso parece ser causado por uma combinação de Parametrização Simples e Busca Dinâmica .

    O SQL Server irá, em alguns casos, parametrizar uma consulta que não é parametrizada. Mas isso às vezes pode causar problemas com conversões implícitas.

    O que aconteceu aqui é que ele se converteu N'Alex'em @1 nvarchar(4000) = 'Alex'. Então transformou isso WHERE DisplayName <> @1em uma Busca Dinâmica . A estimativa de cardinalidade pode ter sido imprecisa devido à sua consulta original ser varcharem vez de nvarchar.

    Isso pode ter algumas desvantagens, principalmente na estimativa de cardinalidade, mas tem o benefício de que o servidor pode buscar nos dois sentidos a partir de um predicado de desigualdade.

    Em outras palavras,

    WHERE DisplayName <> @1

    torna-se duas buscas com a lógica de:

    WHERE DisplayName < @1 OR DisplayName > @1

    Os Sorte Merge Intervalnão são realmente necessários aqui, porque os dois predicados devem, por definição, ser disjuntos, mas essa é a configuração padrão da Busca dinâmica.

    • 7

relate perguntas