Suponha que eu tenha uma tabela com 1000 registros e tenho a consulta abaixo, que retornaria 7 registros no total:
SELECT *
FROM MyTable
WHERE IndexedColumn > 5000
AND OtherIndexedColumn = 2
Como as duas colunas têm índices atualizados, o SQL Server pode fazer suposições e encontrar os valores mais rapidamente e ambas as consultas são SARGable (idealmente menos leituras). No entanto, suponha que eu precise ter certeza de que o valor não é igual a outro valor, digamos 12 para uma coluna diferente, então eu teria que adicionar
AND AnotherIndexedColumn <> 12
Se essa for a última instrução da WHEREcláusula, o SQL Server usa o SARGability nas duas primeiras instruções WHERE para primeiro filtrar, obter as 7 linhas e, em seguida, verificar se cada linha das 7 não é igual a 12 ou se aplica o <>para cada linha no conjunto de dados original de 1000 linhas?
O motivo que estou perguntando é porque estou ciente que poderia usar uma subconsulta ou CTE para fazer a primeira parte do filtro SARGable, depois das 7 linhas, olhe e veja se cada uma não é igual, mas é a consulta otimizador já está fazendo isso nos bastidores, ou é melhor fazer isso sozinho?
Em teoria, e particularmente nas versões modernas do SQL Server, a ordem das cláusulas WHERE não faz nenhuma diferença. O SQL Server geralmente processará os filtros na ordem mais eficiente e escolherá o índice que determinar que permitirá a consulta mais eficiente. Uma diferença que pode ocorrer é quando a cláusula WHERE inclui critérios JOIN ou aplica filtros a colunas unidas externas; outras diferenças podem entrar em jogo quando opções como FORCE ORDER ou sinalizadores de rastreamento específicos estão em uso.
Reescrever como um CTE para "forçar" o SQL Server a processar um filtro dentro do CTE primeiro não funciona - o SQL Server irá reescrevê-lo de qualquer maneira e processá-lo na ordem que julgar melhor. É por isso que, por exemplo, você não pode escapar de erros de conversão inválidos usando um CTE ou uma subconsulta para primeiro filtrar os dados inválidos - o SQL Server ainda pode apresentar os dados inválidos para a conversão antes que qualquer filtro faça qualquer coisa.
(Erland reclamou sobre isso em Connect #537419 .)
Portanto, novamente, geralmente , não reescreva seu código SQL para tentar enganar o otimizador ou impedir que ele faça algo estúpido. Há ocasiões em que ele pode escolher o índice errado que pode ser resolvido alterando a própria consulta, mas lide com isso em situações em que você já acredita que o otimizador escolheu o índice errado (e antes de resolvê-los, elimine as causas mais prováveis como parâmetro sniffing, estatísticas ruins, etc.).