> Data > Indexer pour optimiser les performances des tris

Indexer pour optimiser les performances des tris

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Dusan Petrovic et Christian Unterreitmeier
La définition d'index sur les colonnes de tri peut améliorer les performances de manière exceptionnelle
Un index approprié peut considérablement améliorer les performances de tri de SQL Server.
Par exemple, la définition d'un index clusterisé sur une colonne de tri contraint la base de données à  stocker les enregistrements sous forme triée, ce qui permet d'extraire les données sans avoir à  réaliser de tri supplémentaire. Vous noterez que SQL Server 7.0 et les versions antérieures permettent de créer des index uniquement en ordre croissant.
Par conséquent, si votre requête nécessite des données dans un ordre décroissant, il faudra certainement effectuer un tri supplémentaire et utiliser des tables de travail internes pour générer des données dans l'ordre approprié.
Cependant, SQL Server 2000 permet de créer des index aussi bien dans un ordre croissant que décroissant.

SQL Server 2000 permet de créer des index aussi bien dans un ordre croissant que décroissant.

SQL Server 7.0 effectue une opération de tri lorsqu'on utilise la clause ORDER BY. L'optimiseur de requêtes de SQL Server est également susceptible d'utiliser une opération de tri pour traiter une requête utilisant les clauses GROUP BY, DISTINCT ou UNION. En revanche, on peut utiliser l'indicateur d'index FAST pour éviter le tri des données.
Cela indique à  l'optimiseur de requêtes de SQL Server qu'il doit utiliser un index non clusterisé correspondant à  la clause ORDER BY, éliminant ainsi la nécessité du tri. Observons comment SQL Server gère les clauses GROUP BY, DISTINCT et UNION pour trier les données, puis analysons comment les différentes techniques d'indexation peuvent améliorer les performances des requêtes nécessitant des données triées.

La clause GROUP BY permet d’organiser les données par groupes ; tous les enregistrements
d’un groupe possèdent la même valeur pour la (les) colonne(s) spécifiée(s) dans
la clause GROUP BY. Par exemple, la requête

SELECT customerid
FROM orders
GROUP BY customerid

trie les données par groupes en fonction de la colonne customerid. SQL Server
renvoie ensuite un enregistrement pour chaque valeur de colonne distincte. On
peut grouper une table en fonction de n’importe quelle combinaison de ses colonnes.
Dans les versions antérieures à  SQL Server 7.0, le logiciel trie toujours les
données avant de constituer les groupes. Pour sa part, SQL Server 7.0 peut utiliser
une technique appelée hachage, au lieu de trier par groupes de colonnes.

Alternative aux index, le hachage offre un accès rapide à  des enregistrements
particuliers d’une table. Pour mener à  bien le hachage, SQL Server utilise une
fonction de hachage ( h()) pour répartir uniformément toutes les pages dans une
table de hash-coding. La fonction de hachage identifie chaque entrée de la table
qui dispose d’un nombre fixe de buckets. Un bucket est un ensemble de pointeurs
servant d’index à  une page.
Chaque bucket contient des entrées d’index composées de deux valeurs : la valeur
de la colonne à  partir de laquelle la base de données conçoit la fonction de hachage,
et un pointeur vers l’enregistrement correspondant. La fonction de hachage associe
ensuite chaque valeur de colonne à  un nombre, et crée une entrée d’index pour
chaque enregistrement de la table.

L’optimiseur de requêtes de SQL Server décide d’utiliser le tri ou le hachage
pour créer des groupes en fonction de l’opération qui sera la plus performante.
Si vous avez défini un index clusterisé pour la colonne spécifiée dans la clause
GROUP BY, l’optimiseur de requêtes utilise souvent le tri car l’index clusterisé
trie physiquement tous les enregistrements de la table sur le disque. L’optimiseur
peut également choisir d’utiliser le tri si on a défini un index non-clusterisé
pour la colonne GROUP BY si cette méthode offre le traitement le plus rapide.
Cependant, si on n’a pas défini ce type d’index, l’optimiseur de requêtes peut
utiliser le hachage. SQL Server fournit également deux indicateurs de traitement
de requêtes (HASH GROUP et ORDER GROUP) que l’on peut utiliser pour contrôler
l’opération GROUP BY. L’indicateur HASH GROUP oblige l’optimiseur à  utiliser le
hachage pour créer les groupes, et l’indicateur ORDER GROUP à  utiliser le tri.

Lors de l’utilisation de la clause GROUP BY avec les versions de SQL Server antérieures
à  la version 7.0, les résultats des requêtes sont donnés dans l’ordre des colonnes
GROUP BY. Par contre, en ce qui concerne SQL Server 7.0, l’ordre des résultats
dépend de la technique de groupage choisie (ou imposée) par l’optimiseur de requêtes.
Si l’optimiseur utilise le tri, SQL Server affiche des résultats triés. Si l’optimiseur
utilise le hachage, la base de données affiche les enregistrements de la table
tels qu’ils apparaissent dans la table de hachage. Cela peut correspondre -ou
pas-à  l’ordre attendu. Sans clause ORDER BY, on n’a, par définition, aucun ordre
inhérent pour les données d’une base de données relationnelle. Par conséquent,
pour garantir un résultat ordonné, utilisez la clause ORDER BY.

Téléchargez gratuitement cette ressource

Endpoint Security : Etude IDC Enjeux & Perspectives

Endpoint Security : Etude IDC Enjeux & Perspectives

Quel est l'état de l'art des solutions de Endpoint Security et les perspectives associées à leur utilisation ? Comment garantir la sécurité des environnements sensibles en bloquant au plus tôt les cyber attaques sophistiquées, avant qu’elles n'impactent durablement vos environnements de travail ?

Data - Par iTPro.fr - Publié le 24 juin 2010