Qu'est-ce qui rend une instruction SQL sargable?

Par définition (du moins d'après ce que j'ai vu), sargable signifie qu'une requête est capable d'avoir le moteur de requête pour optimiser le plan d'exécution utilisé par la requête. J'ai essayé de chercher les réponses, mais il ne semble pas y avoir beaucoup de choses sur le sujet. La question est donc de savoir ce qui rend ou non une requête SQL sargable. Toute documentation serait grandement appréciée.

Pour référence: SARGable

La chose la plus courante qui rend une requête non-sargable est d'inclure un champ à l'intérieur d'une fonction dans la clause where:

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

L'optimiseur SQL ne peut pas utiliser d'index sur myDate, même s'il en existe un. Il devra littéralement évaluer cette fonction pour chaque ligne du tableau. Beaucoup mieux à utiliser:

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

Quelques autres exemples:

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()) 

Ne faites pas ça:

WHERE Field LIKE '%blah%'

Cela provoque une analyse de table / index, car la valeur LIKE commence par un caractère générique.

Ne faites pas ça:

WHERE FUNCTION(Field) = 'BLAH'

Cela provoque une analyse de table / index.

Le serveur de base de données devra évaluer FUNCTION () par rapport à chaque ligne du tableau, puis le comparer à 'BLAH'.

Si possible, faites-le à l'envers:

WHERE Field = INVERSE_FUNCTION('BLAH')

Cela exécutera INVERSE_FUNCTION () contre le paramètre une fois et permettra toujours l'utilisation de l'index.

Dans cette réponse, je suppose que la base de données a des index de couverture suffisants. Il y a suffisamment de questions sur ce sujet .

La plupart du temps, la sargabilité d'une requête est déterminée par le point de basculement des index associés. Le point de basculement définit la différence entre rechercher et analyser un index tout en joignant une table ou un ensemble de résultats à une autre. Une recherche est bien sûr beaucoup plus rapide que l'analyse d'une table entière, mais lorsque vous devez rechercher un grand nombre de lignes, une analyse peut avoir plus de sens.

Ainsi, entre autres, une instruction SQL est plus discutable lorsque l'optimiseur s'attend à ce que le nombre de lignes résultantes d'une table soit inférieur au point de basculement d'un index possible sur la table suivante.

Vous pouvez trouver un article détaillé et un exemple ici .

Pour qu'une opération soit considérée comme sargable, il ne suffit pas qu'elle puisse simplement utiliser un index existant. Dans l'exemple ci-dessus, l'ajout d'un appel de fonction à une colonne indexée dans la clause where profiterait très probablement de l'index défini. Il va "scanner" aka récupérer toutes les valeurs de cette colonne (index) puis éliminer celles qui ne correspondent pas à la valeur de filtre fournie. Il n'est pas encore suffisamment efficace pour les tables avec un nombre élevé de lignes. Ce qui définit vraiment la sargabilité, c'est la capacité de la requête à parcourir l'index b-tree en utilisant la méthode de recherche binaire qui repose sur l'élimination à demi-ensemble pour le tableau des éléments triés. En SQL, il serait affiché sur le plan d'exécution comme une "recherche d'index".