Solución:
[NOTE: If you are going to downvote this answer, please leave a comment explaining why. It has already been downvoted many times, and finally ypercube (thank you) explained at least one reason why. I can’t remove the answer because it is accepted, so you might as well help to improve it.]
Según este intercambio en Microsoft, GETDATE() cambió de ser constante dentro de una consulta a no determinista en SQL Server 2005. En retrospectiva, no creo que eso sea exacto. Creo que era completamente no determinista antes de SQL Server 2005 y luego pirateó algo llamado “constante de tiempo de ejecución no determinista” desde SQL Server 2005 “. La última frase realmente parece significar” constante dentro de una consulta “.
(Y GETDATE() se define como inequívoca y orgullosamente no determinista, sin calificadores).
Por desgracia, en SQL Server, no determinista no significa que se evalúe una función para cada fila. SQL Server realmente hace que esto sea innecesariamente complicado y ambiguo con muy poca documentación sobre el tema.
En la práctica, la llamada a la función se evalúa cuando la consulta se está ejecutando en lugar de una vez cuando se compila la consulta y su valor cambia cada vez que se llama. En la práctica, GETDATE() solo se evalúa una vez para cada expresión en la que se utiliza, en Tiempo de ejecución en vez de tiempo de compilación. Sin embargo, Microsoft pone rand() y getdate() en una categoría especial, denominada funciones constantes de tiempo de ejecución no deterministas. Por el contrario, Postgres no pasa por esos obstáculos, solo llama a funciones que tienen un valor constante cuando se ejecutan como “estables”.
A pesar del comentario de Martin Smith, la documentación de SQL Server simplemente no es explícita sobre este asunto: GETDATE() se describe como “constante de tiempo de ejecución no determinista” y “no determinista”, pero ese término no se explica realmente. El único lugar donde encontré el término, por ejemplo, las siguientes líneas en la documentación dicen que no se deben usar funciones no deterministas en subconsultas. Sería un consejo tonto para la “constante de tiempo de ejecución no determinista”.
Sugeriría usar una variable con una constante incluso dentro de una consulta, para que tenga un valor consistente. Esto también deja bastante clara la intención: desea un valor único dentro de la consulta. Dentro de una sola consulta, puede hacer algo como:
select . . .
from (select getdate() as now) params cross join
. . .
En realidad, esta es una sugerencia de que deberían evaluar solo una vez en la consulta, pero puede haber excepciones. La confusión surge porque getdate() devuelve el mismo valor en todas las filas diferentes, pero puede devolver valores diferentes en columnas diferentes. Cada expresión con getdate() se evalúa de forma independiente. Esto es obvio si ejecuta:
select rand(), rand()
from (values (1), (2), (3)) v(x);
Dentro de un procedimiento almacenado, querrá tener un solo valor en una variable. ¿Qué sucede si el procedimiento almacenado se ejecuta cuando pasa la medianoche y cambia la fecha? ¿Qué impacto tiene eso en los resultados?
En cuanto al rendimiento, supongo que la búsqueda de fecha / hora es mínima y para una consulta se produce una vez por expresión cuando la consulta comienza a ejecutarse. Esto no debería ser realmente un problema de rendimiento, sino más bien un problema de coherencia del código.
Mi sugerencia sería usar una variable principalmente porque si tiene un proceso de larga ejecución, el GetDate() el valor puede ser diferente entre llamadas.
A menos que solo esté utilizando el Date parte de GetDate() entonces estará seguro de que siempre está usando el mismo valor.
Una razón para usar una variable con getdate() o funciones como suser_sname() es una gran diferencia de rendimiento si está insertando filas, o si está haciendo un GROUP BY. Notará esto si inserta una gran cantidad de filas.
Yo mismo sufrí esto al migrar 300GB de datos a varias tablas.