Searchable Arguments, ou S-ARGs, ou comment optimiser la clause WHERE d’une requête

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

3 réflexions au sujet de « Searchable Arguments, ou S-ARGs, ou comment optimiser la clause WHERE d’une requête »

Laisser un commentaire