Funciones de SQL Server que se consideran constantes de tiempo de ejecución
se evalúan una sola vez. GETDATE() es una función de este tipo, y DATEADD(..., constant, GETDATE()) es también una constante de tiempo de ejecución. Al dejar la llamada de función real dentro de la consulta, le permite al optimizador ver qué valor se usará realmente (a diferencia de un olfato de valor variable) y luego puede ajustar sus estimaciones de cardinalidad en consecuencia, posiblemente creando un mejor plan.
También lea esto:Resolución de problemas de bajo rendimiento de consultas:plegado constante y evaluación de expresiones durante la estimación de cardinalidad .
@Martin Smith
Puede ejecutar esta consulta:
set nocount on;
declare @known int;
select @known = count(*) from sysobjects;
declare @cnt int = @known;
while @cnt = @known
select @cnt = count(*) from sysobjects where getdate()=getdate()
select @cnt, @known;
En mi caso, después de 22 segundos, llegó al caso límite y salió del ciclo. Lo importante es que el bucle salió con @cnt cero . Uno esperaría que si getdate() se evalúa por fila, entonces obtendríamos un @cnt diferente del conteo @conocido correcto, pero no 0. El hecho de que @cnt sea cero cuando existe el bucle muestra cada getdate() se evaluó una vez y luego se usó el mismo valor constante para cada fila DONDE filtrado (sin coincidencia). Soy consciente de que un ejemplo positivo no prueba un teorema, pero creo que el caso es suficientemente concluyente.
