Différence entre index clusterisé et non clusterisé

Question

J'ai besoin d'ajouter index approprié à mes tables et j'ai besoin d'aide.

Je suis confus et j'ai besoin de clarifier quelques points:

• Devrais-je utiliser l'index pour les colonnes non-int? Pourquoi pourquoi pas

• J'ai beaucoup lu sur clustered et non-clustered index, mais je ne suis toujours pas en mesure de décider quand utiliser l'un par rapport à l'autre. Un bon exemple pourrait m'aider et aider beaucoup d'autres développeurs.

Je sais que je ne devrais pas utiliser d'index pour des colonnes ou des tables souvent mises à jour. A quoi dois-je faire attention et comment puis-je savoir que tout va bien avant de passer en phase de test?

Answer 1

Vous devez vraiment séparer deux problèmes:

1) la clé primaire est une construction logique - une des clés candidates qui identifie de manière unique et fiable toutes les lignes de votre table. Cela peut être n'importe quoi, vraiment - un INT, un GUID, une chaîne - choisissez ce qui convient le mieux à votre scénario.

2) la clé de clustering (la ou les colonnes qui définissent "l'index clusterisé" de la table) - il s'agit d'un physique = chose liée au stockage, et ici, un type de données petit, stable et en augmentation constante est votre meilleur choix - INT ou BIGINT comme option par défaut.

Par défaut, la clé primaire d'une table SQL Server est également utilisée comme clé de clustering - mais cela n'a pas besoin d'être ainsi!

Une règle empirique que je voudrais appliquer est la suivante: toute table "normale" (celle que vous utilisez pour stocker des données, c'est-à-dire une table de consultation, etc.) doit avoir une clé de clustering. Il n'y a vraiment aucun intérêt à ne pas avoir de clé de clustering. En réalité, contrairement aux idées reçues, le fait d’avoir une clé de clustering accélère réellement toutes les opérations courantes - même les insertions et les suppressions (étant donné que l’organisation des tables est différente et généralement meilleure qu'avec un heap - une table sans cluster clé).

Kimberly Tripp, la reine de l'indexation propose un grand nombre d'excellents articles sur le pourquoi d'une clé de regroupement et sur le type de colonnes à utiliser au mieux comme clé de regroupement. Etant donné que vous n’en obtenez qu’une par table, il est de la plus haute importance de choisir la clé de clustering droite - et pas n'importe quelle clé de clustering.

• GUID en tant que PRIMARY KEY et/ou clé en cluster
• Le débat sur l'index clusterisé continue
• Clé de clustering en augmentation constante - le débat sur les index clusterisés .......... encore!
• L'espace disque est bon marché - c'est pas le point!

Marc

Answer 2

Un index clusterisé modifie la manière dont les lignes sont stockées. Lorsque vous créez un index en cluster sur une colonne (ou plusieurs colonnes), SQL Server trie les lignes de la table en fonction de cette ou ces colonnes. C'est comme un dictionnaire, où tous les mots sont triés par ordre alphabétique dans tout le livre.

En revanche, un index non clusterisé ne modifie pas la manière dont les lignes sont stockées dans la table. Il crée dans la table un objet complètement différent contenant la ou les colonnes sélectionnées pour l’indexation et un pointeur vers les lignes de la table contenant les données. C'est comme un index dans les dernières pages d'un livre, où les mots-clés sont triés et contiennent le numéro de page du matériau du livre pour une référence plus rapide.

Answer 3

Vous devriez utiliser des index pour améliorer les performances du serveur SQL. Cela implique généralement que les colonnes utilisées pour rechercher des lignes dans une table sont indexées.

Les index clusterisés permettent au serveur SQL de classer les lignes sur le disque en fonction de l'ordre des index. Cela implique que si vous accédez aux données dans l'ordre d'un index clusterisé, les données seront présentes sur le disque dans le bon ordre. Toutefois, si les colonnes qui ont un index clusterisé sont fréquemment modifiées, les lignes se déplaceront sur le disque, ce qui entraînera une surcharge, ce qui n’est généralement pas une bonne idée.

Avoir beaucoup d'index n'est pas bon non plus. Ils coûtent pour maintenir. Commencez donc par les plus évidents, puis dressez un profil pour voir ceux qui vous manquent et qui pourraient bénéficier. Vous n'avez pas besoin d'eux dès le départ, ils peuvent être ajoutés plus tard.

La plupart des types de données de colonne peuvent être utilisés lors de l'indexation, mais il est préférable que les petites colonnes soient indexées plutôt que les grandes. De plus, il est courant de créer des index sur des groupes de colonnes (par exemple, pays + ville + rue).

De plus, vous ne remarquerez pas de problèmes de performances tant que vos tables ne contiendront pas assez de données. Une autre chose à considérer est que SQL Server a besoin de statistiques pour optimiser correctement ses requêtes. Assurez-vous donc de le générer.

Answer 4

Comparaison d'un index non clusterisé avec un index clusterisé avec un exemple

Comme exemple d'index non clusterisé, supposons qu'un index non clusterisé se trouve dans la colonne EmployeeID. Un index non-cluster stockera à la fois la valeur du

ID employé

ET un pointeur sur la ligne de la table des employés où cette valeur est réellement stockée. Mais un index clusterisé, en revanche, stockera réellement les données de ligne pour un EmployeeID particulier. Ainsi, si vous exécutez une requête qui recherche un EmployeeID de 15, les données des autres colonnes de la table, telles que

EmployeeName, EmployeeAddress, etc.

. seront tous réellement stockés dans le nœud feuille de l'index clusterisé lui-même.

Cela signifie qu'avec un index non cluster, un travail supplémentaire est nécessaire pour suivre ce pointeur sur la ligne de la table afin d'extraire les autres valeurs souhaitées, par opposition à un index cluster pouvant simplement accéder à la ligne car elle est stockée dans le fichier. même ordre que l'index clusterisé lui-même. Ainsi, la lecture d'un index clusterisé est généralement plus rapide que celle d'un index non clusterisé.

Answer 5

En général, utilisez un index sur une colonne qui sera utilisée (beaucoup) pour rechercher dans la table, telle qu'une clé primaire (qui possède par défaut un index en cluster). Par exemple, si vous avez la requête (en pseudocode)

SELECT * FROM FOO WHERE FOO.BAR = 2

Vous voudrez peut-être mettre un index sur FOO.BAR. Un index clusterisé doit être utilisé sur une colonne qui sera utilisée pour le tri. Un index en cluster est utilisé pour trier les lignes sur le disque, vous ne pouvez donc en avoir qu'une par table. Par exemple si vous avez la requête

SELECT * FROM FOO ORDER BY FOO.BAR ASCENDING

Vous voudrez peut-être envisager un index en cluster sur FOO.BAR.

La considération la plus importante est probablement combien de temps vos requêtes prennent. Si une requête prend peu de temps ou n’est pas utilisée très souvent, il ne vaut peut-être pas la peine d’ajouter des index. Comme toujours, profilez d'abord, puis optimisez. SQL Server Studio peut vous donner des suggestions sur l’optimisation, et MSDN contient des informations 1 qui pourraient vous être utiles.

Answer 6

plus rapide à lire que les non-grappes, car les données sont physiquement triées par ordre d'index, nous ne pouvons en créer qu'une par table.

plus rapide pour l'opération d'insertion et de mise à jour qu'un index de cluster. nous pouvons créer un nombre n d'index non cluster.