¿Por qué aparece un error de consulta con un conjunto de resultados vacío en SQL Server 2012?

Al ejecutar las siguientes consultas en MS SQL Server 2012, la segunda consulta falla pero no la primera. Además, cuando se ejecuta sin las cláusulas where, ambas consultas fallarán. No sé por qué fallaría, ya que ambos deberían tener conjuntos de resultados vacíos. Cualquier ayuda / visión es 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

Una mirada inicial a los planes de ejecución muestra que la expresión 1/0se define en los operadores de Calcular Escalar:

Ahora, a pesar de que los planes de ejecución comienzan a ejecutarse en el extremo izquierdo, invocando iterativamente Openy GetRowmétodos en iteradores secundarios para devolver resultados, SQL Server 2005 y posterior contiene una optimización mediante la cual las expresiones a menudo solo son definidas por un Escalar de cómputo, con evaluación diferida hasta un posterior La operación requiere el resultado :

En este caso, el resultado de la expresión solo es necesario cuando se ensambla la fila para regresar al cliente (lo que se puede pensar que ocurre en el SELECTícono verde ). Según esa lógica, la evaluación diferida significaría que la expresión nunca se evalúa porque ninguno de los planes genera una fila de retorno. Para trabajar un poco el punto, ni el Clustered Index Seek ni el Table Scan devuelven una fila, por lo que no hay una fila para ensamblar y devolver al cliente.

Sin embargo, hay una optimización separada por la cual algunas expresiones pueden identificarse como constantes de tiempo de ejecución y evaluarse una vez antes de que comience la ejecución de la consulta . En este caso, se puede encontrar una indicación de esto en el XML del plan de presentación (plan de búsqueda de índice agrupado a la izquierda, plan de escaneo de tabla a la derecha):

Escribí más sobre los mecanismos subyacentes y cómo pueden afectar el rendimiento en esta publicación de blog . Usando la información proporcionada allí, podemos modificar la primera consulta para que ambas expresiones se evalúen y se almacenen en caché antes de que comience la ejecución:

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

select 1/0
from #temp2
where id = 1

Ahora, el primer plan también contiene una referencia de expresión constante, y ambas consultas producen el mensaje de error. El XML para la primera consulta contiene:

Más información: Calcular escalares, expresiones y rendimiento

Voy a adivinar inteligentemente (y en el proceso probablemente atraiga a un gurú de SQL Server que pueda dar una respuesta realmente detallada).

La primera consulta aborda la ejecución como:

1. Escanear el índice de la clave primaria
2. Busque los valores en la tabla de datos necesarios para la consulta

Elige esta ruta porque tiene una wherecláusula en la clave primaria. Nunca llega al segundo paso, por lo que la consulta no falla.

El segundo no tiene una clave principal para ejecutarse, por lo que aborda la consulta como:

1. Haga un escaneo completo de la tabla de los datos y recupere los valores necesarios

Uno de esos valores está 1/0causando el problema.

Este es un ejemplo de SQL Server que optimiza la consulta. En su mayor parte, esto es algo bueno. SQL Server moverá las condiciones de la selectoperación de escaneo a la tabla. Esto a menudo ahorra pasos en la evaluación de la consulta.

Pero, esta optimización no es algo bueno absoluto. De hecho, parece violar la documentación de SQL Server en sí misma que dice que la wherecláusula se evalúa antes que select. Bueno, podrían tener una explicación erudita de lo que esto significa. Sin embargo, para la mayoría de los humanos, procesar lógicamente el whereantes del selectsignificaría (entre otras cosas) "no generar selecterrores de cláusula en filas no devueltas al usuario".