Que signifient réellement les index cluster et non cluster?

J'ai une exposition limitée à DB et n'ai utilisé DB que comme programmeur d'application. Je veux savoir Clusteredet Non clustered indexes. J'ai googlé et ce que j'ai trouvé était:

Un index cluster est un type d'index spécial qui réorganise la façon dont les enregistrements de la table sont stockés physiquement. Par conséquent, la table ne peut avoir qu'un seul index cluster. Les nœuds terminaux d'un index cluster contiennent les pages de données. Un index non cluster est un type d'index spécial dans lequel l'ordre logique de l'index ne correspond pas à l'ordre physique stocké des lignes sur le disque. 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.

Ce que j'ai trouvé dans SO était Quelles sont les différences entre un index cluster et un index non cluster? .

Quelqu'un peut-il expliquer cela en anglais simple?

Avec un index clusterisé, les lignes sont stockées physiquement sur le disque dans le même ordre que l'index. Par conséquent, il ne peut y avoir qu'un seul index cluster.

Avec un index non clusterisé, il existe une deuxième liste contenant des pointeurs vers les lignes physiques. Vous pouvez avoir de nombreux index non clusterisés, bien que chaque nouvel index augmente le temps nécessaire pour écrire de nouveaux enregistrements.

Il est généralement plus rapide de lire à partir d'un index clusterisé si vous souhaitez récupérer toutes les colonnes. Vous n'avez pas besoin d'aller d'abord à l'index puis à la table.

L'écriture dans une table avec un index clusterisé peut être plus lente s'il est nécessaire de réorganiser les données.

Un index cluster signifie que vous dites à la base de données de stocker des valeurs proches réellement proches les unes des autres sur le disque. Cela présente l'avantage d'une analyse / récupération rapide des enregistrements appartenant à une certaine plage de valeurs d'index groupées.

Par exemple, vous avez deux tables, Client et Commande:

Customer
----------
ID
Name
Address

Order
----------
ID
CustomerID
Price

Si vous souhaitez récupérer rapidement toutes les commandes d'un client particulier, vous pouvez créer un index clusterisé dans la colonne "CustomerID" de la table Order. De cette façon, les enregistrements avec le même CustomerID seront physiquement stockés les uns à côté des autres sur le disque (en cluster), ce qui accélère leur récupération.

PS L'index sur CustomerID ne sera évidemment pas unique, vous devez donc soit ajouter un deuxième champ pour "unifier" l'index, soit laisser la base de données gérer cela pour vous, mais c'est une autre histoire.

Concernant les index multiples. Vous ne pouvez avoir qu'un seul index cluster par table car cela définit la façon dont les données sont physiquement organisées. Si vous souhaitez une analogie, imaginez une grande salle avec de nombreuses tables. Vous pouvez soit mettre ces tables pour former plusieurs lignes, soit les rassembler pour former une grande table de conférence, mais pas dans les deux sens en même temps. Une table peut avoir d'autres index, ils pointeront alors vers les entrées de l'index cluster qui à son tour diront enfin où trouver les données réelles.

Dans le stockage orienté ligne SQL Server, les index cluster et non cluster sont organisés en arborescences B.

( Source de l'image )

La principale différence entre les index cluster et les index non cluster est que le niveau feuille de l'index cluster est la table. Cela a deux implications.

1. Les lignes des pages feuilles d'index cluster contiennent toujours quelque chose pour chacune des colonnes (non éparses) de la table (soit la valeur, soit un pointeur sur la valeur réelle).
2. L'index cluster est la copie principale d'une table.

Les index non clusterisés peuvent également faire le point 1 en utilisant la INCLUDEclause (depuis SQL Server 2005) pour inclure explicitement toutes les colonnes non clés mais ce sont des représentations secondaires et il y a toujours une autre copie des données autour (la table elle-même).

CREATE TABLE T
(
A INT,
B INT,
C INT,
D INT
)

CREATE UNIQUE CLUSTERED INDEX ci ON T(A,B)
CREATE UNIQUE NONCLUSTERED INDEX nci ON T(A,B) INCLUDE (C,D)

Les deux indices ci-dessus seront presque identiques. Avec les pages d'index de niveau supérieur contenant des valeurs pour les colonnes clés A,Bet les pages de niveau feuille contenantA,B,C,D

Il ne peut y avoir qu'un seul index cluster par table, car les lignes de données elles-mêmes peuvent être triées dans un seul ordre.

La citation ci-dessus des livres en ligne de SQL Server provoque beaucoup de confusion

À mon avis, ce serait beaucoup mieux formulé comme.

Il ne peut y avoir qu'un seul index cluster par table, car les lignes de niveau feuille de l'index cluster sont les lignes de la table.

La citation en ligne des livres n'est pas incorrecte mais vous devez être clair que le "tri" des indices non clusterisés et clusterisés est logique et non physique. Si vous lisez les pages au niveau feuille en suivant la liste chaînée et lisez les lignes de la page dans l'ordre du tableau d'emplacements, vous lirez les lignes d'index dans l'ordre trié mais physiquement les pages peuvent ne pas être triées. La croyance courante selon laquelle avec un index clusterisé les lignes sont toujours stockées physiquement sur le disque dans le même ordre que la clé d' indexation est fausse.

Ce serait une mise en œuvre absurde. Par exemple, si une ligne est insérée au milieu d'une table de 4 Go, SQL Server n'a pas à copier 2 Go de données dans le fichier pour faire de la place pour la ligne nouvellement insérée.

Au lieu de cela, un fractionnement de page se produit. Chaque page au niveau feuille des index cluster et non cluster a l'adresse ( File:Page) de la page suivante et précédente dans l'ordre de clé logique. Ces pages n'ont pas besoin d'être contiguës ou dans un ordre clé.

Par exemple, la chaîne de page liée peut être 1:2000 <-> 1:157 <-> 1:7053

Lorsqu'un fractionnement de page se produit, une nouvelle page est allouée de n'importe où dans le groupe de fichiers (à partir d'une étendue mixte, pour les petites tables, ou d'une étendue uniforme non vide appartenant à cet objet ou d'une étendue uniforme nouvellement allouée). Cela pourrait même ne pas être dans le même fichier si le groupe de fichiers en contient plusieurs.

Le degré de différence entre l'ordre logique et la contiguïté de la version physique idéalisée est le degré de fragmentation logique.

Dans une base de données nouvellement créée avec un seul fichier, j'ai exécuté ce qui suit.

CREATE TABLE T
  (
     X TINYINT NOT NULL,
     Y CHAR(3000) NULL
  );

CREATE CLUSTERED INDEX ix
  ON T(X);

GO

--Insert 100 rows with values 1 - 100 in random order
DECLARE @C1 AS CURSOR,
        @X  AS INT

SET @C1 = CURSOR FAST_FORWARD
FOR SELECT number
    FROM   master..spt_values
    WHERE  type = 'P'
           AND number BETWEEN 1 AND 100
    ORDER  BY CRYPT_GEN_RANDOM(4)

OPEN @C1;

FETCH NEXT FROM @C1 INTO @X;

WHILE @@FETCH_STATUS = 0
  BEGIN
      INSERT INTO T (X)
      VALUES        (@X);

      FETCH NEXT FROM @C1 INTO @X;
  END

Puis vérifié la mise en page avec

SELECT page_id,
       X,
       geometry::Point(page_id, X, 0).STBuffer(1)
FROM   T
       CROSS APPLY sys.fn_PhysLocCracker( %% physloc %% )
ORDER  BY page_id

Les résultats étaient partout. La première ligne dans l'ordre des touches (avec la valeur 1 - mise en évidence avec la flèche ci-dessous) était sur presque la dernière page physique.

La fragmentation peut être réduite ou supprimée en reconstruisant ou en réorganisant un index pour augmenter la corrélation entre l'ordre logique et l'ordre physique.

Après avoir couru

ALTER INDEX ix ON T REBUILD;

J'ai le suivant

Si la table n'a pas d'index cluster, elle est appelée un tas.

Les index non clusterisés peuvent être construits sur un segment de mémoire ou un index clusterisé. Ils contiennent toujours un localisateur de ligne sur la table de base. Dans le cas d'un segment de mémoire, il s'agit d'un identificateur de ligne physique (rid) et se compose de trois composants (File: Page: Slot). Dans le cas d'un index cluster, le localisateur de ligne est logique (la clé d'index cluster).

Dans ce dernier cas, si l'index non groupé inclut déjà naturellement la ou les colonnes de clé CI sous forme de colonnes de clé NCI ou de INCLUDEcolonnes -d, rien n'est ajouté. Sinon, la ou les colonnes de clés CI manquantes sont ajoutées silencieusement au NCI.

SQL Server garantit toujours que les colonnes clés sont uniques pour les deux types d'index. Le mécanisme dans lequel cela est appliqué pour les index non déclarés comme uniques diffère cependant entre les deux types d'index.

Les index clusterisés sont uniquifierajoutés pour toutes les lignes avec des valeurs clés qui dupliquent une ligne existante. Ceci est juste un entier croissant.

Pour les index non cluster non déclarés comme uniques, SQL Server ajoute silencieusement le localisateur de ligne à la clé d'index non cluster. Cela s'applique à toutes les lignes, pas seulement à celles qui sont en fait des doublons.

La nomenclature clusterisée vs non clusterisée est également utilisée pour les index de magasin de colonnes. Le papier Améliorations apportées à la colonne SQL Server stocke les états

Bien que les données du magasin de colonnes ne soient pas vraiment "en cluster" sur aucune clé, nous avons décidé de conserver la convention SQL Server traditionnelle de faire référence à l'index principal comme un index en cluster.

Je me rends compte que c'est une très vieille question, mais j'ai pensé proposer une analogie pour aider à illustrer les bonnes réponses ci-dessus.

INDEX CLUSTRÉ

Si vous entrez dans une bibliothèque publique, vous constaterez que les livres sont tous classés dans un ordre particulier (très probablement le système décimal Dewey ou DDS). Cela correspond à l ' "index clusterisé" des livres. Si le DDS # du livre que vous voulez était 005.7565 F736s, vous commenceriez par localiser la rangée d'étagères qui est étiquetée 001-099ou quelque chose comme ça. (Ce signe d'extrémité à la fin de la pile correspond à un «nœud intermédiaire» dans l'index.) Finalement, vous descendriez jusqu'à l'étagère spécifique étiquetée 005.7450 - 005.7600, puis vous numérisiez jusqu'à ce que vous trouviez le livre avec le DDS # spécifié, et à ce point, vous avez trouvé votre livre.

INDICE NON CLUSTERED

Mais si vous n'êtes pas entré dans la bibliothèque avec le DDS # de votre livre mémorisé, alors vous auriez besoin d'un deuxième index pour vous aider. Dans les temps anciens, vous trouverez à l'avant de la bibliothèque un magnifique bureau de tiroirs connu sous le nom de "Catalogue de cartes". Il y avait des milliers de cartes 3x5 - une pour chaque livre, triées par ordre alphabétique (par titre, peut-être). Cela correspond à "l'indice non clusterisé" . Ces catalogues de cartes étaient organisés selon une structure hiérarchique, de sorte que chaque tiroir serait étiqueté avec la gamme de cartes qu'il contenait ( Ka - Klpar exemple, le «nœud intermédiaire»). Encore une fois, vous exploreriez jusqu'à ce que vous trouviez votre livre, mais dans ce cas, une fois que vous l'avez trouvé (c'est-à-dire le "nœud feuille"), vous n'avez pas le livre lui-même,numéro d' index (le DDS #) avec lequel vous pouvez trouver le livre réel dans l'index clusterisé.

Bien sûr, rien n'empêcherait le bibliothécaire de photocopier toutes les cartes et de les trier dans un ordre différent dans un catalogue de cartes distinct. (En règle générale, il y avait au moins deux de ces catalogues: un trié par nom d'auteur et un par titre.) En principe, vous pouvez avoir autant de ces index "non groupés" que vous le souhaitez.

Vous trouverez ci-dessous quelques caractéristiques des index clusterisés et non clusterisés:

Index clusterisés

1. Les index clusterisés sont des index qui identifient de manière unique les lignes d'une table SQL.
2. Chaque table peut avoir exactement un index cluster.
3. Vous pouvez créer un index cluster qui couvre plusieurs colonnes. Par exemple: create Index index_name(col1, col2, col.....).
4. Par défaut, une colonne avec une clé primaire possède déjà un index cluster.

Index non clusterisés

1. Les index non groupés sont comme des index simples. Ils sont juste utilisés pour une récupération rapide des données. Pas sûr d'avoir des données uniques.

Une règle empirique très simple et non technique serait que les index cluster sont généralement utilisés pour votre clé primaire (ou, au moins, une colonne unique) et que les non cluster sont utilisés pour d'autres situations (peut-être une clé étrangère) . En effet, SQL Server créera par défaut un index clusterisé sur vos colonnes de clé primaire. Comme vous l'aurez compris, l'index cluster est lié à la façon dont les données sont triées physiquement sur le disque, ce qui signifie que c'est un bon choix complet pour la plupart des situations.

Index clusterisé

Un index clusterisé détermine l'ordre physique des DONNÉES dans une table.Pour cette raison, une table n'a qu'un seul index clusterisé.

• " dictionnaire " Pas besoin d'autre index, c'est déjà un index selon les mots

Index non clusterisé

Un index non groupé est analogue à un index dans un livre. Les données sont stockées en un seul endroit. L'index est stocké à un autre endroit et l'index a des pointeurs vers l'emplacement de stockage des données. Pour cette raison, une table a plus d'un index non cluster.

• " Livre de chimie " à regarder fixement il y a un index séparé pour pointer l'emplacement du Chapitre et à la "FIN" il y a un autre Index pointant l'emplacement des MOTS communs

Index clusterisé

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 d'index. Il ne peut y avoir qu'un seul index cluster par table, car les lignes de données elles-mêmes peuvent être trié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 d'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.

Vous pouvez ajouter des colonnes non clés au niveau feuille de l'index non cluster pour contourner les limites de clés d'index existantes et exécuter des requêtes entièrement couvertes et indexées. Pour plus d'informations, voir Créer des index avec des colonnes incluses. Pour plus d'informations sur les limites des clés d'index, consultez Spécifications de capacité maximale pour SQL Server.

Référence: https://docs.microsoft.com/en-us/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-described

Permettez-moi de proposer une définition de manuel sur "l'index de clustering", qui est tirée de 15.6.1 de Database Systems: The Complete Book :

Nous pouvons également parler d' index de clustering , qui sont des index sur un ou des attributs tels que tous les tuples avec une valeur fixe pour la clé de recherche de cet index apparaissent sur à peu près aussi peu de blocs que peuvent les contenir.

Pour comprendre la définition, regardons l'exemple 15.10 fourni par le manuel:

Une relation R(a,b)triée par attribut aet stockée dans cet ordre, regroupée en blocs, est sûrement clusterd. Un index sur aest un index de clustering, car pour une valeur donnée aa1, tous les tuples avec cette valeur pour asont consécutifs. Ils apparaissent donc regroupés en blocs, sauf éventuellement pour les premier et dernier blocs qui contiennent la valeur aa1, comme suggéré dans la figure 15.14. Cependant, un index sur b est peu susceptible de se regrouper, car les tuples avec une valeur fixe bseront répartis sur tout le fichier sauf si les valeurs de aet bsont très étroitement corrélées.

Notez que la définition n'impose pas que les blocs de données doivent être contigus sur le disque; il indique seulement que les tuples avec la clé de recherche sont regroupés dans le moins de blocs de données possible.

Un concept connexe est une relation groupée . Une relation est "groupée" si ses tuples sont regroupés en à peu près autant de blocs que peuvent contenir ces tuples. En d'autres termes, du point de vue d'un bloc de disque, s'il contient des tuples de différentes relations, ces relations ne peuvent pas être regroupées (c'est-à-dire qu'il existe un moyen plus compact de stocker une telle relation en échangeant les tuples de cette relation d'autres blocs de disque avec le tuples n'appartient pas à la relation dans le bloc de disque en cours). De toute évidence, R(a,b)dans l'exemple ci-dessus est groupé.

Pour connecter deux concepts ensemble, une relation en cluster peut avoir un index de clustering et un index de non-clustering. Cependant, pour une relation non clusterisée, l'index de clustering n'est possible que si l'index est construit au-dessus de la clé primaire de la relation.

"Cluster" en tant que mot est spammé à tous les niveaux d'abstraction du côté stockage de la base de données (trois niveaux d'abstraction: tuples, blocs, fichier). Un concept appelé " fichier en cluster ", qui décrit si un fichier (une abstraction pour un groupe de blocs (un ou plusieurs blocs de disque)) contient des tuples d'une relation ou de relations différentes. Il ne se rapporte pas au concept d'index de clustering car il est au niveau du fichier.

Cependant, certains supports pédagogiques aiment définir l'index de clustering en fonction de la définition de fichier en cluster. Ces deux types de définitions sont les mêmes au niveau des relations en cluster, qu'elles définissent une relation en cluster en termes de bloc ou de fichier de disque de données. À partir du lien dans ce paragraphe,

Un index sur les attributs A d'un fichier est un index de clustering lorsque: Tous les tuples avec la valeur d'attribut A = a sont stockés séquentiellement (= consécutivement) dans le fichier de données

Le stockage consécutif des tuples revient à dire que "les tuples sont regroupés en à peu près autant de blocs que peuvent éventuellement contenir ces tuples" (avec une différence mineure sur l'un qui parle de fichier, l'autre sur disque). C'est parce que le stockage consécutif de tuple est le moyen d'obtenir "regroupé en aussi peu de blocs que possible pour contenir ces tuples".

Index clusterisé: la contrainte de clé primaire crée automatiquement un index clusterisé si aucun index cluster n'existe déjà sur la table. Les données réelles de l'index cluster peuvent être stockées au niveau feuille de l'index.

Index non clusterisé: les données réelles de l'index non clusterisé ne sont pas directement trouvées au niveau du nœud feuille, mais il doit effectuer une étape supplémentaire pour les trouver car il n'a que les valeurs des localisateurs de lignes pointant vers les données réelles. L'index non cluster ne peut pas être trié en tant qu'index cluster. Il peut y avoir plusieurs index non clusterisés par table, cela dépend en fait de la version du serveur sql que nous utilisons. Fondamentalement, le serveur SQL 2005 autorise 249 index non clusterisés et pour les versions ci-dessus comme 2008, 2016, il autorise 999 index non clusterisés par table.

Index clusterisé - Un index clusterisé définit l'ordre dans lequel les données sont physiquement stockées dans une table. Les données de table peuvent être triées de la seule manière, par conséquent, il ne peut y avoir qu'un seul index clusterisé par table. Dans SQL Server, la contrainte de clé primaire crée automatiquement un index cluster sur cette colonne particulière.

Index non clusterisé- Un index non clusterisé ne trie pas les données physiques à l'intérieur de la table. En fait, un index non clusterisé est stocké à un endroit et les données de table sont stockées à un autre endroit. Ceci est similaire à un manuel où le contenu du livre est situé à un endroit et l'index est situé à un autre. Cela permet plus d'un index non clusterisé par table.Il est important de mentionner ici qu'à l'intérieur du tableau les données seront triées par un index clusterisé. Cependant, à l'intérieur des données d'index non clusterisées sont stockées dans l'ordre spécifié. L'index contient des valeurs de colonne sur lesquelles l'index est créé et l'adresse de l'enregistrement auquel appartient la valeur de colonne. Lorsqu'une requête est émise sur une colonne sur laquelle l'index est créé, la base de données va d'abord accéder à l'index et rechercher l'adresse de la ligne correspondante dans le tableau. Il ira ensuite à cette adresse de ligne et récupérera les autres valeurs de colonne. C'est à cause de cette étape supplémentaire que les index non clusterisés sont plus lents que les index clusterisés.

Différences entre les index cluster et non cluster

1. Il ne peut y avoir qu'un seul index cluster par table. Cependant, vous pouvez créer plusieurs index non clusterisés sur une même table.
2. Les index clusterisés ne trient que les tables. Par conséquent, ils ne consomment pas de stockage supplémentaire. Les index non groupés sont stockés dans un emplacement distinct de la table réelle, ce qui nécessite plus d'espace de stockage.
3. Les index clusterisés sont plus rapides que les index non cluster car ils n'impliquent aucune étape de recherche supplémentaire.

Pour plus d'informations, reportez-vous à cet article.