Bien que beaucoup d’optimisations peuvent être assurées lors du choix du matériel du serveur de base de données, et lors de la conception d’une base de données, il n’en reste pas moins que les requêtes, avant de nécessiter la recherche d’indexes permettant leur optimisation, peuvent être dans un premier temps mises au point au niveau de leur(s) contrainte(s).
C’est ce que montrent les S-ARGs, ou « Searchable Arguments »
Je vais tenter de donner une définition assez complète de ce que sont les S-ARGs.
Un S-ARG est de la forme :
{colonne} {opérateur} {expression}
{expression} {opérateur} {colonne}
Où :
– {colonne} correspond à un nom de colonne, et pas à une fonction, une expression ou encore un concaténation,
– {opérateur} peut être l’un des symboles mathématiques ou encore les clauses IS NULL, BETWEEN et LIKE ‘a%’,
– {expression} est soit une constante, soit une variable valuée à une valeur constante, et est du même type que la colonne dans laquelle elle est recherchée.
Ces clauses sont dites « cherchables » parce que l’optimiseur de requêtes de SQL Server (et de bien d’autres SGBD) se base sur les statistiques pour créer le meilleur plan de requête possible, c’est à dire celui qui donnera la réponse à la requête le plus vite possible et un utilisant le moins de ressources possible.
Ces statistiques sont créées avec les indexes, ou encore automatiquement crées par SQL Server.
Elles portent sur les données présentes dans les colonnes, et ne peuvent pas porter sur les données n’existant pas dans les colonnes.
Donc, si l’expression de la requête n’utilise pas de S-ARGs, les indexes et statistiques ne sont pas utilisables, et le moteur de base de données décide donc d’effectuer un scan de table, ou un scan d’index cluster (celui de la clé primaire), qui est donc long et coûteux.
Dès lors, l’utilisation de prédicats tels que OR, NOT, IS NOT NULL, NOT BETWEEN, NOT IN, NOT EXISTS, LIKE ‘%a%’, LIKE ‘%a’, NOT LIKE ne sont pas « cherchables », et rendent la requête plus lente et plus coûteuse, alors qu’on peut réécrire la plupart des contraintes de requête « non-cherchables » avec des contraintes « cherchables » : on peut ainsi souvent remplacer un OR par un AND, un IN par un BETWEEN, ou tout simplement « inverser » l’expression du prédicat « non-cherchable ».
ElSuket
Tiens j’avais même pas vu que tu avais écrit cela. J’ai complété… Et il faut que j’étende encore mon article :
Sous SQL 2005 et SQL 2008 les cas des opérateurs IN, LIKE et OR sont discutables. On a eu une discussion à ce sujet il n’y a pas si longtemps
http://www.developpez.net/forums/d962232/bases-donnees/ms-sql-server/administration/searchable-arguments-clause-where-optimisee/
A+
Etienne ZINZINDOHOUE
un article intéressant, un complément à ce qu’écrit rudi ou sql pro.