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

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

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%.

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 *)

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.

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.

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.

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.

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.

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.

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é.

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.

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

// 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.