Início / dba / Perguntas / 322999
Accepted
variable
Asked: 2023-02-03 18:07:32 +0800 CST

O SQL garante que `SELECT *` em uma subconsulta será otimizado para evitar uma varredura completa?

  • 772

Estou explorando o rastreamento de consulta de eventos estendidos e tenho dúvidas sobre algumas consultas estranhas, como a seguir:

Exemplo 1:

select top 10  *   from   (   SELECT [id]       ,[date]       ,[ordnum]       ,
[customer]  ,[amt]   ,[gm pc]   FROM [DbName].[dbo].[tblSales]  ) as [_]
where [date]>='2022-01-01T00:00:00.000'

Exemplo 2:

select [_].[id],      [_].[date],   [_].[ordnum],  [_].[customer], [_].[amt], 
[_].[gm pc]  
from   (  SELECT [id] ,[date] ,[ordnum] ,  [customer]  ,[amt]  ,[gm pc]   
FROM [DbName].[dbo].[tblSales]  ) as [_]  where [_].[date] >= 
convert(datetime2, '2020-01-01 00:00:00') 
    and [_].[date] < convert(datetime2, '2021-01-01 00:00:00')

Portanto, na subconsulta, ele seleciona todas as linhas. E então, na consulta externa, ele aplica os critérios where.

Se funcionar literalmente assim, significa que a subconsulta fará a varredura completa da tabela e aplicará a cláusula where ao resultado. Ou essa consulta é otimizada para que a cláusula where seja aplicada diretamente na tabela?

sql-server

2 respostas

  1. Best Answer

    O texto SQL expressa os resultados lógicos necessários. O otimizador baseado em custo do SQL Server encontra uma maneira física eficiente de implementar esse requisito lógico . Os resultados são garantidos como os mesmos (para todos os valores de dados possíveis) conforme especificado pelo SQL, é claro.

    Uma das coisas básicas que o otimizador faz é empurrar as condições de filtragem (predicados) o mais baixo possível (em direção às folhas) do plano de execução.

    Então, sim, para todos os propósitos práticos, exemplos como o seu são 'garantidos' para não serem executados literalmente com uma varredura completa seguida por um filtro. A condição de filtragem normalmente será avaliada como parte da verificação ou, melhor ainda, como uma busca de intervalo de índice se um índice adequado estiver disponível.

    Se funcionar literalmente assim, significa que a subconsulta fará a varredura completa da tabela e aplicará a cláusula where ao resultado.

    Você ainda parece estar pensando em planos de execução como se cada operador executasse até a conclusão antes de passar as linhas resultantes para o próximo operador. Não funciona assim . Veja meu artigo Iterators, Query Plans, and Why They Run Backwards para detalhes.

    • 13

  2. Embora tenha alguns elementos procedimentais, o coração do SQL é a consulta que é declarativa (geralmente declarada como sql sendo uma linguagem declarativa).

    Isso significa que o mecanismo SQL decide como atender à sua solicitação. Como analogia, você diz que gostaria de um hambúrguer, não diz quando virar o hambúrguer ou como fazer o hambúrguer.

    Desde que a resposta/ação esteja correta, como é considerado irrelevante. É claro que todo o resto sendo igual, as pessoas naturalmente prefeririam um mecanismo que respondesse mais rápido, então o mecanismo faz a consulta, analisa o que sabe sobre o banco de dados e tenta escolher o melhor método considerando todas as coisas.

    Isso inclui coisas como armazenar em cache os resultados, usar índices e, sim, mover predicados.

    Teoricamente existe uma ordem definida para cada operação, na prática tudo é opcional e pode ser feito (ou não) em qualquer ordem desde que o resultado esteja correto.

    Por exemplo, se o predicado da cláusula where diz não nulo, mas a própria coluna não é nula, essa verificação pode ser removida totalmente, ela é satisfeita quando o plano de consulta está sendo construído. Ou uma junção à esquerda pode ser transformada em uma junção interna porque a cláusula where diz que a coluna de junção não é nula ou mesmo um valor específico.

    • 1

relate perguntas