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
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Vers l’Industrie 5.0 : quand l’IA agentique change la donne
- Ready For IT 2026 : IA industrialisée, deepfakes et Prix Start-up au cœur des enjeux
- La chaîne d’approvisionnement, point de rupture récurent du SI
- Ready For IT 2026 : quand l’accélération de l’innovation redessine les priorités des décideurs IT
Articles les + lus
Computex 2026 : 5 signaux forts à retenir
La chaîne d’approvisionnement, point de rupture récurent du SI
Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
Analyse Patch Tuesday Mai 2026
À la une de la chaîne Tech
- Computex 2026 : 5 signaux forts à retenir
- La chaîne d’approvisionnement, point de rupture récurent du SI
- Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
- Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
- Analyse Patch Tuesday Mai 2026
