Nie wie, jaka będzie wartość zmiennych podczas kompilowania zapytania. Możesz spróbować OPTION (RECOMPILE) .
Zakładam, że dodanie AND klauzula w zapytaniu (chociaż logicznie rzecz biorąc, nie czyni go bardziej selektywnym) musi wprowadzić w błąd optymalizatora do oszacowania zapytania z większą selektywnością, dając w ten sposób pożądany plan!
W komentarzach mówisz, że wersja bez ExceptionDate = ExceptionDate szacuje się na 88234.8 wiersze i wersja z 8823.48
Generalnie przy braku użytecznych statystyk SQL Server powraca do heurystyki zależnej od typu operatora porównania w predykacie.
Zakłada, że > predykat zwróci na przykład 30% wierszy i że = predykat zwróci 10% wierszy, więc wygląda na to, że po prostu stosuje to bezpośrednio do wyniku pierwszego oszacowania. Ciekawe, że nie bierze pod uwagę faktu, że równa się tutaj przeciwko samej kolumnie!
