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

Question

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

Answer 1

Index clusterisé

• Un seul par table
• Plus rapide à lire que les applications non groupées, les données étant physiquement stockées dans l'ordre d'index

Index non clusterisé

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

Les deux types d'index vont améliorer les performances lorsque vous sélectionnez des données avec des champs qui utilisent l'index mais ralentissent les opérations de mise à jour et d'insertion.

En raison du ralentissement de l'insertion et de la mise à jour, les index en cluster doivent être définis sur un champ qui est normalement incrémentiel, c'est-à-dire Id ou Timestamp.

Normalement, SQL Server utilisera un index uniquement si sa sélectivité est supérieure à 95%.

Answer 2

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 qu'il ne peut y avoir qu'un seul index clusterisé (évidemment). L'accès aux données à l'aide d'un index en cluster est le plus rapide.

Tous les autres index doivent être non groupés. Un index non clusterisé contient un duplicata des données des colonnes indexées conservées ordonnées avec des pointeurs sur les lignes de données réelles (pointeurs sur l'index clusterisé, le cas échéant). Cela signifie que l'accès aux données via un index non cluster doit passer par une couche supplémentaire d'indirection. Toutefois, si vous sélectionnez uniquement les données disponibles dans les colonnes indexées, vous pouvez les récupérer 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 *.)

Answer 3

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 clusterisé par table.

Les index non clusterisé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 clusterisé sur la colonne unique la plus utilisée, généralement la clé PK. Vous devriez toujours avoir un index clusterisé bien sélectionné dans vos tables, à moins d’une raison très convaincante: ne pouvez pas en penser à un seul, mais bon, il est peut-être là-bas. Ne pas le faire apparaît.

Answer 4

Index clusterisé

1. Il ne peut exister qu'un seul index clusterisé pour une table.
2. Généralement créé sur la clé primaire.
3. Les noeuds feuille d'un index en 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'à ce que les versions ultérieures de SQL version 2005 prennent en charge jusqu'à 999 index non clusterisés).
2. Généralement créé sur une touche quelconque.
3. Le noeud feuille d'un index non clusterisé ne comprend pas les pages de données. Au lieu de cela, les nœuds terminaux contiennent des lignes d'index.

Answer 5

Index clusterisé

• Il ne peut y avoir qu'un seul index clusterisé dans une table
• Triez les enregistrements et stockez-les physiquement en fonction de l'ordre
• La récupération de données est plus rapide que les index non clusterisés
• Vous n'avez pas besoin d'espace supplémentaire pour stocker la structure logique

Index non clusterisé

• Il peut y avoir un nombre quelconque d'index non clusterisés dans une table
• N'affectez pas l'ordre physique. Créez un ordre logique pour les lignes de données et utilisez des pointeurs vers des fichiers de données physiques
• L'insertion / mise à jour des données est plus rapide que l'index clusterisé
• Utiliser davantage d'espace pour stocker la structure logique

Hormis ces différences, vous devez savoir que, lorsque la table est non clusterisée (lorsque la table ne possède pas d'index clusterisé), les fichiers de données ne sont pas ordonnés et qu'il utilise la structure de données Heap comme structure de données.

Answer 6

Clustered signifie fondamentalement 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.

Answer 7

Avantages:

Les index clusterisés conviennent parfaitement aux 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 tri si vous utilisez une instruction orderby.

Inconvénients:

Les index clusterisés peuvent ralentir les insertions car les présentations physiques des enregistrements doivent être modifiées au fur et à mesure que les enregistrements sont placés si les nouvelles clés ne sont pas dans un ordre séquentiel.

Answer 8

Un index en 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.

Answer 9

Un index clusterisé est essentiellement une copie triée des données des colonnes indexées.

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

La maintenance d'un index clusterisé, en particulier dans une table fréquemment mise à jour, peut entraîner une baisse des performances. Par conséquent, il peut être préférable de créer un index non clusterisé.

Answer 10

Une base de données indexée comprend deux parties: un ensemble d'enregistrements physiques, classés dans un ordre arbitraire, et un ensemble d'index identifiant la séquence dans laquelle les enregistrements doivent être lus pour obtenir un résultat trié par un critère. S'il n'y a pas de corrélation entre l'agencement physique et l'index, la lecture de tous les enregistrements dans l'ordre peut nécessiter l'exécution d'un grand nombre d'opérations de lecture indépendantes d'un seul enregistrement. Puisqu'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 de manière consécutive sur le disque. Si vous indiquez qu'un index est mis en cluster, la base de données fera des efforts (différentes en fonction de leur importance) pour organiser les choses de sorte que les groupes d'enregistrements consécutifs dans l'index soient consécutifs sur le disque.

Par exemple, si l’on commençait par une base de données vide non clusterisée et ajoutait 10 000 enregistrements de manière aléatoire, les enregistrements seraient probablement ajoutés à la fin dans l’ordre dans lequel ils avaient été ajoutés. La lecture de la base de données dans l'ordre de l'index nécessiterait 10 000 lectures en un enregistrement. Toutefois, si l’on utilisait une base de données en cluster, le système pourrait vérifier lors de l’ajout de chaque enregistrement si l’enregistrement précédent était stocké seul; Si tel est le cas, il peut écrire cet enregistrement avec le nouveau à la fin de la base de données. Il pourrait alors examiner l'enregistrement physique avant les emplacements où se trouvaient les enregistrements déplacés et voir si l'enregistrement suivant était stocké par lui-même. Si tel était le cas, il pourrait déplacer cet enregistrement à cet endroit. En utilisant ce type d’approche, de nombreux enregistrements seraient regroupés par paires, doublant ainsi potentiellement la vitesse de lecture séquentielle.

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 existe un compromis entre le temps requis pour mettre à jour la base de données et le temps nécessaire pour le lire de manière séquentielle. La maintenance d'une base de données en cluster augmentera considérablement la quantité de travail nécessaire pour ajouter, supprimer ou mettre à jour des enregistrements de quelque manière que ce soit qui aurait une incidence sur la séquence de tri. Si la base de données doit être lue séquentiellement beaucoup plus souvent que mise à jour, la mise en cluster peut être une grande victoire. Si la mise à jour est fréquente, mais rarement lue dans l’ordre, la mise en cluster peut être une lourde perte de performances, en particulier si l’ordre dans lequel les éléments sont ajoutés à la base de données est indépendant de leur ordre de tri par rapport à l’index en cluster.

Answer 11

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

En cluster

• Les index clusterisés trient et stockent les lignes de données dans la table ou la vue. sur la base de leurs valeurs clés. Ce sont les colonnes incluses dans le définition d'index. Il ne peut y avoir qu'un seul index clusterisé par table, car les lignes de données elles-mêmes ne peuvent être stockées que dans un seul ordre.
• La seule fois où les lignes de données d'une table sont stockées dans l'ordre de tri est lorsque la table contient un index clusterisé. Quand 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 un fichier non ordonné structure appelée un tas.

Non clusterisé

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

Answer 12

Vous avez peut-être lu la partie théorique des articles ci-dessus:

-L'index clusterisé, comme nous pouvons le voir directement sur des points, c'est-à-dire son index direct, de sorte que la recherche prend moins de temps. En outre, le stockage de l'index ne nécessite pas de mémoire / espace supplémentaire

-Bien que dans Index non clusterisé, il pointe indirectement sur l'index clusterisé puis il accédera à l'enregistrement réel. En raison de sa nature indirecte, il lui faudra plus de temps pour y accéder.Il a également besoin de son propre mémoire / espace pour stocker l'index