> Tech > Index ordonnés en clusters

Index ordonnés en clusters

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Lorsque vous créez la clé d’un index ordonné en clusters, il faut avoir conscience de plusieurs facteurs. Etant donné la manière dont le moteur de stockage a évolué dans le domaine de la gestion des tables de base entre la version SQL Server 6.5 et les versions 7.0 et ultérieures

Index ordonnés en clusters

de SQL Server, les aspects essentiels que j’examine concernant un index ordonné en clusters portent sur le fait que la clé doit être unique, étroite et statique.

Unique. Une clé d’index ordonné en clusters doit être unique car elle sert de clé de recherche pour tous les index non ordonnés en clusters. Par exemple, imaginez un index situé à la fin d’un livre. Pour vous permettre de trouver les informations vers lesquelles pointe une entrée d’index, cette dernière doit être unique. Dans le cas contraire, vous ne trouverez pas l’élément précis recherché. D’une manière similaire, l’index ordonné en clusters doit être unique. Toutefois, SQL Server n’impose pas de créer votre clé d’index ordonné en clusters sur une colonne unique. Vous pouvez le faire sur n’importe quelle colonne. Si la clé d’index ordonné en clusters n’est pas unique, SQL Server fera en sorte qu’elle le soit en ajoutant un entier sur 4 octets aux données. Il faut avoir conscience que la création de l’index ordonné en clusters sur une clé non unique entraîne un traitement supplémentaire au moment de la création de l’index, gaspille de l’espace disque, génère des coûts supplémentaires au cours des opérations INSERT et UPDATE, et, dans SQL Server 2000, ajoute le coût de la reconstruction d’un index ordonné en clusters, une opération très vraisemblablement nécessaire du fait du choix peu judicieux de la clé d’index ordonné en clusters.

Etroite. Une clé d’index ordonné en clusters doit être étroite (à savoir, composée du nombre le plus réduit possible de colonnes), pour une partie des mêmes raisons qui justifient son unicité. Comme la clé d’index ordonné en clusters sert de clé de recherche pour l’ensemble des index non ordonnés en clusters, elle est dupliquée dans ces index en question. Si la clé est trop large (autrement dit, si elle comporte plus de colonnes que nécessaire), tous les index non ordonnés en clusters auront une largeur excessive, d’où un gaspillage d’espace disque, des coûts supplémentaires pendant les opérations INSERT et UPDATE, et des délais plus longs (en raison de la taille plus importante) pour reconstruire ces structures d’index. Par conséquent, que recouvre la notion d’étroite ? Elle signifie l’utilisation du nombre le plus réduit d’octets pour aider à définir de manière unique vos lignes, au moyen d’une valeur numérique étroite si possible car SQL Server gère les données de type numeric bien plus efficacement que les autres types de données.

Statique. Une clé d’index ordonné en clusters doit être statique pour certaines des mêmes raisons qui justifient son caractère unique et étroit. Si la clé est employée comme clé de recherche pour tous les index non ordonnés en clusters, elle est dupliquée sur l’ensemble d’entre eux. En fait, pour une table donnée, la clé d’index ordonné en clusters constituera le type de données le plus dupliqué. Si les données changent, il faudra mettre à jour la valeur dans la table de base et dans chaque index non ordonné en clusters. Si la clé change, l’enregistrement sera déplacé. Le changement de place de l’enregistrement sera générateur de fragmentation. Tout comme les index non ordonnés en clusters trop larges, la fragmentation gaspille de l’espace disque et génère des coûts supplémentaires lors des opérations INSERT et UPDATE. La fragmentation augmente également la durée nécessaire pour exécuter les mises à jour de données (en raison du déplacement des enregistrements et du besoin probable de fractionnements consécutifs) et accroît la maintenance.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010