Quelles sont les différences entre un index cluster et un index non cluster?

277

Quelles sont les différences entre a clusteredet a non-clustered index?

Eric Labashosky
la source
8
Vous ne pouvez avoir qu'un seul index cluster par table. Mais il y a plein d'autres différences ...
Tom Robinson
5
Un index cluster décrit en fait l'ordre dans lequel les enregistrements sont physiquement stockés sur le disque, d'où la raison pour laquelle vous ne pouvez en avoir qu'un. Un index non clusterisé définit un ordre logique qui ne correspond pas à l'ordre physique sur le disque.
Josh
1
Clustered signifie essentiellement que les données sont dans cet ordre physique dans le tableau. C'est pourquoi vous ne pouvez en avoir qu'un par table. Unclustered signifie que c'est "seulement" un ordre logique.
Biri
2
@biri qu'est-ce qu'un ordre "logique"? un index non clusterisé stocke les clés d'index physiquement et stocke un pointeur vers la table, à savoir la clé d'index cluster.
Stephanie Page
@Stephanie Page: logique du point de vue de la table. Bien sûr, les index non clusterisés sont classés physiquement dans l'index lui-même.
Biri

Réponses:

268

Index clusterisé

  • Un seul par table
  • Lecture plus rapide que non groupée car les données sont physiquement stockées dans l'ordre des index

Index non groupé

  • Peut être utilisé plusieurs fois par table
  • Plus rapide pour les opérations d'insertion et de mise à jour qu'un index clusterisé

Les deux types d'index amélioreront les performances lors de la sélection de données avec des champs qui utilisent l'index mais ralentiront les opérations de mise à jour et d'insertion.

En raison de l'insertion et de la mise à jour plus lentes, les index clusterisés doivent être définis sur un champ qui est normalement incrémentiel, c'est-à-dire l'ID ou l'horodatage.

SQL Server n'utilisera normalement un index que si sa sélectivité est supérieure à 95%.

Martynnw
la source
9
Il y a également des considérations de stockage. Lors de l'insertion de lignes dans une table sans index clusterisé, les lignes sont stockées dos à dos sur la page et la mise à jour d'une ligne peut entraîner le déplacement de la ligne à la fin du tableau, laissant un espace vide et fragmentant la table et les index.
Jeremiah Peschka
4
vous n'avez pas à vous soucier de ce qu'est x. Tout ce que vous devez savoir, c'est que pour une application avec des millions d'utilisateurs, x sera important
Pacerier
14
C'est purement un dogme. Ce n'est pas "plus rapide à lire car les données sont stockées dans l'ordre". Il est plus rapide à lire car vous évitez la lecture d'un index ET PUIS la lecture de la table. Il est plus rapide de parcourir la plage (si cela est significatif) car les données sont stockées dans l'ordre. c'est-à-dire que le facteur de regroupement est parfait.
Stephanie Page
6
L'idée que 95% des enregistrements doivent être uniques est également une erreur. Supposons que vous ayez une table avec 1 000 000 lignes et que vous indexiez une colonne avec 500 000 clés. 0% sont uniques mais chaque clé renvoie 2 lignes sur un million. Cet index est absolument utile indépendamment du fait que 0% des enregistrements sont uniques.
Stephanie Page
2
"les données sont physiquement stockées dans l'ordre des index" que voulez-vous dire par là? À un certain niveau, cela est trivialement vrai parce que les pages de données et les pages de feuille d'index sont une seule et même chose - donc, évidemment, l'ordre de l'un décrit l'ordre de l'autre. Cependant, ce n'est pas nécessairement dans un ordre particulier tel que l'ordre de la clé d'index stackoverflow.com/questions/1251636/…
Martin Smith
79

Les index clusterisés ordonnent physiquement les données sur le disque. Cela signifie qu'aucune donnée supplémentaire n'est nécessaire pour l'index, mais il ne peut y avoir qu'un seul index clusterisé (évidemment). L'accès aux données à l'aide d'un index cluster est le plus rapide.

Tous les autres index doivent être non groupés. Un index non clusterisé a un double des données des colonnes indexées conservées ordonnées avec des pointeurs vers les lignes de données réelles (pointeurs vers l'index clusterisé s'il y en a un). Cela signifie que l'accès aux données via un index non clusterisé doit passer par une couche supplémentaire d'indirection. Cependant, si vous sélectionnez uniquement les données disponibles dans les colonnes indexées, vous pouvez récupérer les données directement à partir des données d'index dupliquées (c'est pourquoi il est judicieux de sélectionner uniquement les colonnes dont vous avez besoin et de ne pas utiliser *)

rslite
la source
3
`` Cependant, si vous sélectionnez uniquement les données disponibles dans les colonnes indexées, vous pouvez récupérer les données directement à partir des données d'index dupliquées '' - oui, c'est l'exception importante à l'heuristique d'index cluster préféré. Je suppose que dans ce cas, vous avez essentiellement un index clusterisé, mais moins de données dans la table que vous interrogez afin qu'il puisse potentiellement être lu plus rapidement sur le disque.
satnhak
34

Les index clusterisés sont stockés physiquement sur la table. Cela signifie qu'ils sont les plus rapides et que vous ne pouvez avoir qu'un seul index cluster par table.

Les index non groupés sont stockés séparément et vous pouvez en avoir autant que vous le souhaitez.

La meilleure option consiste à définir votre index cluster sur la colonne unique la plus utilisée, généralement le PK. Vous devriez toujours avoir un index cluster bien sélectionné dans vos tables, sauf si une raison très convaincante - ne peut pas penser à un seul, mais bon, il peut être là - pour ne pas le faire se présente.

Santiago Cepas
la source
3
pouvez-vous nous en dire plus sur "nous devrions toujours avoir un index clusterisé dans nos tables"? sans élaboration, cette affirmation est tout simplement fausse à cause du mot toujours
Pacerier
1
Tu as raison Pacerier, il ne faut pas utiliser les déclarations absolues à la légère. Bien que je ne connaisse pas un seul cas où vous ne devriez pas avoir un index cluster bien sélectionné, un tel cas peut exister, j'ai donc changé ma réponse pour une version plus générique.
Santiago Cepas
28

Index clusterisé

  1. Il ne peut y avoir qu'un seul index cluster pour une table.
  2. Généralement réalisé sur la clé primaire.
  3. Les nœuds terminaux d'un index cluster contiennent les pages de données.

Index non clusterisé

  1. Il ne peut y avoir que 249 index non clusterisés pour une table (jusqu'à la version SQL 2005, les versions ultérieures prennent en charge jusqu'à 999 index non clusterisés).
  2. Généralement réalisé sur n'importe quelle touche.
  3. Le nœud feuille d'un index non cluster ne se compose pas des pages de données. Au lieu de cela, les nœuds terminaux contiennent des lignes d'index.
Jojo
la source
24

Index clusterisé

  • Un seul index cluster peut être présent dans une table
  • Trier les enregistrements et les stocker physiquement selon la commande
  • La récupération des données est plus rapide que les index non clusterisés
  • Ne nécessite pas d'espace supplémentaire pour stocker la structure logique

Index non groupé

  • Il peut y avoir n'importe quel nombre d'index non cluster dans une table
  • N'affecte pas l'ordre physique. Créer un ordre logique pour les lignes de données et utiliser des pointeurs vers des fichiers de données physiques
  • L'insertion / mise à jour des données est plus rapide que l'index clusterisé
  • Utilisez un espace supplémentaire pour stocker la structure logique

En dehors de ces différences, vous devez savoir que lorsque la table n'est pas en cluster (lorsque la table n'a pas d'index cluster), les fichiers de données ne sont pas ordonnés et utilisent la structure de données du tas comme structure de données.

Lasitha Yapa
la source
10

Clustered signifie essentiellement que les données sont dans cet ordre physique dans la table. C'est pourquoi vous ne pouvez en avoir qu'un par table.

Unclustered signifie que c'est "seulement" un ordre logique.

Biri
la source
9

Avantages:

Les index clusterisés fonctionnent très bien pour les plages (par exemple, sélectionnez * dans my_table où my_key entre @min et @max)

Dans certaines conditions, le SGBD n'aura pas à effectuer de travail de tri si vous utilisez une instruction orderby.

Les inconvénients:

Les index clusterisés peuvent ralentir les insertions car les dispositions physiques des enregistrements doivent être modifiées à mesure que les enregistrements sont insérés si les nouvelles clés ne sont pas dans un ordre séquentiel.

Giovanni Galbo
la source
6

Un index cluster est essentiellement une copie triée des données dans les colonnes indexées.

Le principal avantage d'un index cluster est que lorsque votre requête (recherche) localise les données dans l'index, aucune E / S supplémentaire n'est nécessaire pour récupérer ces données.

Les frais généraux liés à la gestion d'un index cluster, en particulier dans une table fréquemment mise à jour, peuvent entraîner de mauvaises performances et pour cette raison, il peut être préférable de créer un index non cluster.

Ed Guiness
la source
6

Une base de données indexée comprend deux parties: un ensemble d'enregistrements physiques, qui sont organisés dans un ordre arbitraire, et un ensemble d'index qui identifient la séquence dans laquelle les enregistrements doivent être lus pour produire un résultat trié par un certain critère. S'il n'y a pas de corrélation entre l'arrangement physique et l'index, la lecture de tous les enregistrements dans l'ordre peut nécessiter de nombreuses opérations de lecture d'un seul enregistrement indépendantes. Dans la mesure où une base de données peut lire des dizaines d'enregistrements consécutifs en moins de temps qu'il n'en faudrait pour lire deux enregistrements non consécutifs, les performances peuvent être améliorées si les enregistrements consécutifs dans l'index sont également stockés consécutivement sur le disque.

Par exemple, si l'on devait commencer avec une base de données non en cluster vide et ajouter 10 000 enregistrements dans un ordre aléatoire, les enregistrements seraient probablement ajoutés à la fin dans l'ordre où ils ont été ajoutés. La lecture de la base de données dans l'ordre par l'index nécessiterait 10 000 lectures à un enregistrement. Si l'on devait utiliser une base de données en cluster, cependant, le système pourrait vérifier lors de l'ajout de chaque enregistrement si l'enregistrement précédent a été stocké par lui-même; s'il constatait que c'était le cas, il pourrait écrire cet enregistrement avec le nouveau à la fin de la base de données. Il pourrait alors regarder l'enregistrement physique avant les emplacements où résidaient les enregistrements déplacés et voir si l'enregistrement qui suivait qui était stocké par lui-même. S'il jugeait que c'était le cas, il pourrait déplacer ce record à cet endroit. L'utilisation de ce type d'approche entraînerait le regroupement de nombreux enregistrements par paires,

En réalité, les bases de données en cluster utilisent des algorithmes plus sophistiqués que cela. Un élément clé à noter, cependant, est qu'il y a un compromis entre le temps requis pour mettre à jour la base de données et le temps nécessaire pour le lire séquentiellement. La maintenance d'une base de données en cluster augmentera considérablement la quantité de travail requise pour ajouter, supprimer ou mettre à jour des enregistrements d'une manière qui pourrait affecter la séquence de tri. Si la base de données sera lue séquentiellement beaucoup plus souvent qu'elle ne sera mise à jour, le clustering peut être une grande victoire. S'il est mis à jour souvent mais rarement lu en séquence, le clustering peut être un gros gouffre de performances, surtout si la séquence dans laquelle les éléments sont ajoutés à la base de données est indépendante de leur ordre de tri en ce qui concerne l'index clusterisé.

supercat
la source
5

Un index cluster décrit en fait l'ordre dans lequel les enregistrements sont physiquement stockés sur le disque, d'où la raison pour laquelle vous ne pouvez en avoir qu'un.

Un index non clusterisé définit un ordre logique qui ne correspond pas à l'ordre physique sur le disque.

Josh
la source
2

Vous avez peut-être passé en revue la partie théorique des messages ci-dessus:

-L'index cluster comme nous pouvons voir les points directement à enregistrer, c'est-à-dire son direct, donc cela prend moins de temps pour une recherche. De plus, il ne faudra pas de mémoire / d'espace supplémentaire pour stocker l'index

-Bien que, dans un index non clusterisé, il pointe indirectement vers l'index clusterisé, puis il accédera à l'enregistrement réel, en raison de sa nature indirecte, il lui faudra un peu plus de temps pour accéder.Il a également besoin de sa propre mémoire / espace pour stocker le indice

entrez la description de l'image ici

Nandkishor Nangre
la source
0

// Copié depuis MSDN, le deuxième point d'index non clusterisé n'est pas clairement mentionné dans les autres réponses.

Clustered

  • Les index clusterisés trient et stockent les lignes de données dans la table ou la vue en fonction de leurs valeurs clés. Ce sont les colonnes incluses dans la définition de l'index. Il ne peut y avoir qu'un seul index clusterisé par table, car les lignes de données elles-mêmes peuvent être stockées dans un seul ordre.
  • La seule fois où les lignes de données d'une table sont stockées dans un ordre trié, c'est lorsque la table contient un index clusterisé. Lorsqu'une table a un index clusterisé, la table est appelée une table clusterisée. Si une table n'a pas d'index clusterisé, ses lignes de données sont stockées dans une structure non ordonnée appelée tas.

Non clusterisé

  • Les index non clusterisés ont une structure distincte des lignes de données. Un index non cluster contient les valeurs de clé d'index non cluster et
    chaque entrée de valeur de clé a un pointeur sur la ligne de données qui contient la valeur de clé.
  • Le pointeur d'une ligne d'index dans un index non cluster vers une ligne de données est appelé localisateur de ligne. La structure du localisateur de lignes varie selon que les pages de données sont stockées dans un segment de mémoire ou une table en cluster. Pour un segment de mémoire, un localisateur de ligne est un pointeur sur la ligne. Pour une table en cluster, le localisateur de ligne est la clé d'index en cluster.
Deepak Mishra
la source