Analysons à présent, la manière dont des index différents peuvent améliorer les performances des requêtes nécessitant des données triées. La requête suivante récupère tous les enregistrements des commandes ayant la valeur customerid égale à WHITC et utilise la clause ORDER BY pour trier les résultats en fonction de la colonne
Utilisation des index pour l’optimisation des tris
orderdate :
Use Northwind
select orderid, customerid, orderdate
from orders
where customerid = ‘WHITC’
order by orderdate
Pour créer un index non clusterisé portant sur la colonne customerid, utilisez
l’instruction suivante :
create index i_customerid on orders (customerid)
L’écran 3illustre le plan d’exécution des requêtes après la création d’un index
non clusterisé sur customerid. Le plan d’exécution des requêtes indique que l’optimiseur
de requêtes accède en premier lieu à l’index existant, puis trie l’ensemble des
enregistrements formant le résultat. Est-il possible d’améliorer les performances
des requêtes en créant un second index non clusterisé sur la colonne triée ? Ou
est-il préférable de définir un index composite (index conçu à partir de plusieurs
colonnes) au lieu de deux index distincts ? Pour trouver la réponse, considérons
deux autres exemples de requête.
L’instruction suivante crée un second index non clusterisé distinct sur la colonne
triée orderdate :
create index i_orderdate on orders (orderdate)
L’écran 4 présente le plan d’exécution des requêtes après avoir ajouté le second
index distinct ; on peut constater qu’il n’existe aucune différence entre ce plan
d’exécution et celui de la requête exécutée avec un seul index de l’Ecran 3.
Cependant, la création d’un index non clusterisé composite pour la requête offre
une amélioration significative des performances. Pour créer un index composite
basé sur customerid et orderdate, exécutez l’instruction suivante :
create index i_custom_order on orders (customerid, orderdate)
L’écran 5 illustre le plan d’exécution de la requête après avoir créé l’index
composite. Ce plan d’exécution présente deux avantages sur les plans précédents.
Premièrement, la requête effectue deux opérations au lieu de trois pour obtenir
ses résultats (l’instruction SELECT ne compte pas comme une opération). Ensuite,
l’optimiseur n’utilise pas le tri qui est, généralement, une opération coûteuse.
L’optimiseur n’a pas besoin du tri car l’index composite i_custom_order offre
un accès aux enregistrements répondant au critère de la requête (customerid =
‘WHITC’) et trie l’ensemble des résultats en fonction de la colonne orderdate.
Téléchargez cette ressource

Guide de Threat Intelligence : quand, quoi et comment ?
La Threat Intelligence (TI) rassemble des données, des informations et des analyses détaillées, dans le but de fournir aux RSSI des informations pertinentes, précises et exploitables pour lutter contre les attaques et d'autres problèmes liés à la cybersécurité. Découvrez dans ce Guide comment maximiser les bénéfices de la TI pour votre organisation.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- 7 conseils pour anticiper la cryptographie post-quantique
- Le DevSecOps, un passage obligé pour la sécurité des identités
- Soirée 10 ans du Club des Décideurs Informatique Côte-Basque
- Les décideurs informatiques français s’inquiètent de la conformité de leurs données
- L’IA ouvre la voie à une nouvelle ère de la robotique avec la sophistication de ses robots marcheurs
