Encontrei essa condição ao otimizar um SP, há uma parte do plano de execução que realmente não entendo: o SQL Server faz uma varredura de índice e filtra os resultados. Qual é a razão para o SQL Server fazer isso, em vez de fazer tudo na varredura de índice ?
Por exemplo:
O índice já contém todos os campos usados pelo WHERE . Expandi a operação Index Scan , e ela executa parte do where com alguns parâmetros envolvidos (totalmente esperado). Em seguida, expandi e inspecionei a operação Filter , e o que ela faz é aplicar alguma outra filtragem em alguns campos de data e hora já avaliados pelo Index Scan , além de algumas outras condições em alguns outros parâmetros do SP.
O que está acontecendo aqui? Obviamente, não me importo com minha consulta específica, esse não é o ponto, estou tentando entender quais condições podem fazer com que isso aconteça.
Os operadores de filtro são frequentemente usados para predicados não SARGable, ou quando os predicados são muito complicados para serem enviados efetivamente para a operação de acesso ao índice.
No seu caso, estou disposto a apostar que é uma série de predicados opcionais. Estes não são SARGable: Conor vs. Parâmetros Opcionais .
Se o seu código estiver fazendo algo como
col = @var or @var IS NULL, ele se enquadra nessa categoria e pode resultar no operador de filtro.