Início / dba / Perguntas / 58888
Accepted
DavidN
Asked: 2014-02-14 10:36:41 +0800 CST

Por que o erro de consulta com conjunto de resultados vazio no SQL Server 2012?

  • 772

Ao executar as seguintes consultas no MS SQL Server 2012, a segunda consulta falha, mas não a primeira. Além disso, quando executadas sem as cláusulas where, ambas as consultas falharão. Não sei por que qualquer um deles falharia, já que ambos deveriam ter conjuntos de resultados vazios. Qualquer ajuda/insight é apreciada.

create table #temp
(id     int primary key)

create table #temp2
(id     int)

select 1/0
from #temp
where id = 1

select 1/0
from #temp2
where id = 1
sql-server sql-server-2012

2 respostas

  1. Best Answer

    Uma olhada inicial nos planos de execução mostra que a expressão 1/0é definida nos operadores Compute Scalar:

    Planos gráficos

    Agora, embora os planos de execução comecem a ser executados na extrema esquerda, chamando iterativamente Opene GetRowmétodos em iteradores filhos para retornar resultados, o SQL Server 2005 e posterior contém uma otimização em que as expressões geralmente são definidas apenas por um Compute Scalar, com avaliação adiada até um próximo operação requer o resultado :

    Os operadores Compute Scalar que aparecem em Showplans gerados por SET STATISTICS XML podem não conter o elemento RunTimeInformation. Em planos de execução gráficos, linhas reais, religações reais e retrocessos reais podem estar ausentes da janela Propriedades quando a opção Incluir plano de execução real é selecionada no SQL Server Management Studio. Quando isso ocorre, significa que, embora esses operadores tenham sido usados ​​no plano de consulta compilado, seu trabalho foi executado por outros operadores no plano de consulta em tempo de execução. Observe também que o número de execuções na saída Showplan gerada por SET STATISTICS PROFILE é equivalente à soma de religações e retrocessos em Showplans gerados por SET STATISTICS XML. De: MSDN Books Online

    Neste caso, o resultado da expressão só é necessário na hora de montar a linha para retorno ao cliente (o que você pode imaginar que ocorre no SELECTícone verde). Por essa lógica, a avaliação adiada significaria que a expressão nunca é avaliada porque nenhum dos planos gera uma linha de retorno. Para trabalhar um pouco o ponto, nem o Clustered Index Seek nem o Table Scan retornam uma linha, então não há nenhuma linha para montar para retornar ao cliente.

    No entanto, há uma otimização separada em que algumas expressões podem ser identificadas como constantes de tempo de execução e, portanto, avaliadas uma vez antes do início da execução da consulta .

    Neste caso*, uma indicação de que isso ocorreu pode ser encontrada no showplan XML (plano Clustered Index Seek à esquerda, plano Table Scan à direita):

    plano de execução XML

    Escrevi mais sobre os mecanismos subjacentes e como eles podem afetar o desempenho neste post de blog . Usando as informações fornecidas lá, podemos modificar a primeira consulta para que ambas as expressões sejam avaliadas e armazenadas em cache antes do início da execução:

    select 1/0 * CONVERT(integer, @@DBTS)
from #temp
where id = 1

select 1/0
from #temp2
where id = 1

    Agora, o primeiro plano também contém uma referência de expressão constante e ambas as consultas produzem a mensagem de erro. O XML para a primeira consulta contém:

    Expressão Constante

    Mais informações: escalares de computação, expressões e desempenho

    Um exemplo em que um erro é relatado devido ao cache constante de tempo de execução, mas não há indicação no plano de execução (gráfico ou XML):

    SELECT TOP (1) id
FROM #temp2
WHERE id = 1
ORDER BY 1/0;

    plano misterioso

    • 41

  2. Vou adivinhar de forma inteligente (e no processo provavelmente atrair um guru do SQL Server que pode dar uma resposta realmente detalhada).

    A primeira consulta aborda a execução como:

    1. Examine o índice de chave primária
    2. Procure os valores na tabela de dados necessários para a consulta

    Ele escolhe esse caminho porque você tem uma wherecláusula na chave primária. Ele nunca chega à segunda etapa, portanto, a consulta não falha.

    O segundo não possui uma chave primária para ser executado, portanto aborda a consulta como:

    1. Faça uma varredura completa da tabela dos dados e recupere os valores necessários

    Um desses valores está 1/0causando o problema.

    Este é um exemplo de SQL Server otimizando a consulta. Na maioria das vezes, isso é uma coisa boa. O SQL Server moverá as condições da selectoperação de verificação da tabela. Isso geralmente economiza etapas na avaliação da consulta.

    Mas essa otimização não é uma coisa boa absoluta. Na verdade, parece violar a própria documentação do SQL Server , que diz que a wherecláusula é avaliada antes do select. Bem, eles podem ter alguma explicação erudita para o que isso significa. Para a maioria dos humanos, no entanto, processar logicamente o whereantes do selectsignificaria (entre outras coisas) "não gerar selecterros -cláusula em linhas não retornadas ao usuário".

    • 22

relate perguntas