O que faz uma instrução SQL sargable?

Por definição (pelo menos do que eu vi) sargable significa que uma consulta é capaz de ter o mecanismo de consulta otimizar o plano de execução que a consulta usa. Eu tentei procurar as respostas, mas não parece haver muito sobre o assunto. Então a questão é, o que faz ou não uma consulta SQL sargable? Qualquer documentação seria muito apreciada.

Para referência: SARGable

A coisa mais comum que tornará uma consulta não-sargable é include um campo dentro de uma function na cláusula where:

SELECT ... FROM ... WHERE Year(myDate) = 2008 

O otimizador SQL não pode usar um índice no myDate, mesmo que exista. Terá literalmente que avaliar essa function para cada linha da tabela. Muito melhor usar:

 WHERE myDate >= '01-01-2008' AND myDate < '01-01-2009' 

Alguns outros exemplos:

 Bad: Select ... WHERE isNull(FullName,'Ed Jones') = 'Ed Jones' Fixed: Select ... WHERE ((FullName = 'Ed Jones') OR (FullName IS NULL)) Bad: Select ... WHERE SUBSTRING(DealerName,4) = 'Ford' Fixed: Select ... WHERE DealerName Like 'Ford%' Bad: Select ... WHERE DateDiff(mm,OrderDate,GetDate()) >= 30 Fixed: Select ... WHERE OrderDate < DateAdd(mm,-30,GetDate()) 

Não faça isso:

 WHERE Field LIKE '%blah%' 

Isso causa uma varredura de tabela / índice, porque o valor LIKE começa com um caractere curinga.

Não faça isso:

 WHERE FUNCTION(Field) = 'BLAH' 

Isso causa uma varredura de tabela / índice.

O servidor de database terá que avaliar FUNCTION () em cada linha da tabela e, em seguida, compará-la com ‘BLAH’.

Se possível, faça-o ao contrário:

 WHERE Field = INVERSE_FUNCTION('BLAH') 

Isso executará INVERSE_FUNCTION () no parâmetro uma vez e ainda permitirá o uso do índice.

Nesta resposta, presumo que o database tenha índices de cobertura suficientes. Há perguntas suficientes sobre esse tópico .

Muitas vezes, a sargabilidade de uma consulta é determinada pelo ponto de inflexão dos índices relacionados. O ponto de inflexão define a diferença entre procurar e verificar um índice enquanto une uma tabela ou conjunto de resultados em outro. Uma busca é, é claro, muito mais rápida do que escanear uma tabela inteira, mas quando você precisa buscar muitas fileiras, um escaneamento pode fazer mais sentido.

Portanto, entre outras coisas, uma instrução SQL é mais sutil quando o otimizador espera que o número de linhas resultantes de uma tabela seja menor que o ponto de inflexão de um possível índice na próxima tabela.

Você pode encontrar um post detalhado e um exemplo aqui .

Para uma operação ser considerada sargable, não é suficiente apenas poder usar um índice existente. No exemplo acima, adicionar uma chamada de function a uma coluna indexada na cláusula where, ainda assim, provavelmente levaria alguma vantagem do índice definido. Ele irá “varrer”, também conhecido como recuperar todos os valores dessa coluna (índice) e, em seguida, eliminar aqueles que não corresponderem ao valor do filtro fornecido. Ainda não é eficiente o suficiente para tabelas com alto número de linhas. O que realmente define sargabilidade é a capacidade de consulta para percorrer o índice b-tree usando o método de pesquisa binária que depende da eliminação do meio-conjunto para a matriz de itens classificados. No SQL, ele seria exibido no plano de execução como uma “busca de índice”.