Funkcje programu SQL Server, które są uważane za stałe uruchomieniowe
są oceniane tylko raz. GETDATE() jest taką funkcją, a DATEADD(..., constant, GETDATE()) jest również stałą czasu wykonywania. Pozostawiając rzeczywiste wywołanie funkcji w zapytaniu, pozwalasz optymalizatorowi zobaczyć, jaka wartość zostanie faktycznie użyta (w przeciwieństwie do wąchania wartości zmiennej), a następnie może odpowiednio dostosować swoje oszacowania kardynalności, być może wymyślając lepszy plan.
Przeczytaj także:Rozwiązywanie problemów ze słabą wydajnością zapytań:stałe składanie i ocena wyrażeń podczas szacowania kardynalności .
@Marcin Kowalski
Możesz uruchomić to zapytanie:
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;
W moim przypadku po 22 sekundach trafił w granicę i pętla wyszła. Ważną rzeczą jest to, że pętla została zakończona z @cnt zero . Można by się spodziewać, że jeśli getdate() jest oceniany na wiersz, wtedy otrzymalibyśmy @cnt różną od poprawnej @znanej liczby, ale nie 0. Fakt, że @cnt wynosi zero, gdy pętla istnieje, pokazuje każdą getdate() została oceniona raz, a następnie użyto tej samej stałej wartości dla każdego wiersza, GDZIE filtrowanie (brak dopasowania). Zdaję sobie sprawę, że jeden pozytywny przykład nie dowodzi twierdzenia, ale uważam, że sprawa jest wystarczająco rozstrzygająca.
