Het weet niet wat de waarde van de variabelen zal zijn wanneer het de query compileert. Je zou kunnen proberen OPTION (RECOMPILE) .
Ik neem aan dat de toevoeging van de AND clausule in de zoekopdracht (ook al maakt het deze logischerwijs helemaal niet selectiever) moet de optimiser misleiden om de zoekopdracht met grotere selectiviteit te schatten, waardoor u het plan krijgt dat u wilde!
U zegt in de opmerkingen dat de versie zonder de ExceptionDate = ExceptionDate wordt geschat op 88234.8 rijen en de versie met 8823.48
In het algemeen valt SQL Server bij het ontbreken van bruikbare statistieken terug op heuristieken, afhankelijk van het type vergelijkingsoperator in het predikaat.
Het gaat ervan uit dat een > predikaat zal bijvoorbeeld 30% van de rijen retourneren en dat een = predikaat retourneert 10% van de rijen, dus het lijkt erop dat het dat rechtstreeks toepast op het resultaat van de eerste schatting. Interessant dat het geen rekening houdt met het feit dat de gelijken hier tegen de kolom zelf zijn!