Ce n'Cluster et Non de l'index cluster signifie réellement?

J'ai une exposition limitée à la DB et ont seulement utilisé en tant que base de programmeur de l'application. Je veux savoir à propos de Clustered et Non clustered indexes.
J'ai googlé et ce que j'ai trouvé :

Un index cluster est un type spécial d'index qui réorganise la façon
les enregistrements de la table sont physiquement
stockée. Par conséquent, le tableau ne peut avoir qu'
un index cluster. Les nœuds feuilles
d'un index cluster contenant les données
des pages. Un index non-cluster est un
type spécial de l'index dans lequel l'
l'ordre logique de l'index n'
match de la physique stocké afin de
les lignes sur le disque. Le nœud de feuille de
index non-cluster ne consiste pas à
les pages de données. Au lieu de cela, la feuille
les nœuds contiennent des lignes d'index.

Ce que j'ai trouvé dans la a été Quelles sont les différences entre un cluster et un index non-cluster?.

Quelqu'un peut m'expliquer cela en anglais?

InformationsquelleAutor P.K | 2009-08-09
  1. 976

    Avec un index cluster les lignes sont stockées physiquement sur le disque dans le même ordre que celui de l'indice. Par conséquent, il ne peut être qu'un index cluster.

    Avec un non-clustered index il y a une deuxième liste de pointeurs vers les lignes physiques. Vous pouvez avoir beaucoup de non-cluster indices, bien que chaque nouvel indice augmentera le temps qu'il faut pour écrire de nouveaux records.

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

    Écrit à une table avec un index cluster peut être plus lent, si il est nécessaire de réorganiser les données.

    • Vous devez préciser ce que vous entendez par "physiquement".
    • physiquement comme dans les bits stockés sur le disque
    • “Il ne peut donc être qu'un index cluster.”: Je ne vois pas le point, et SQL montre chaque jour, vous pouvez commander sur plusieurs indices ou des colonnes. Par ailleurs, une question complémentaire: j'ai entendu dire qu'avec MS‑SQL server, une clé primaire définit un index cluster... est-il vrai avec d'autres bases de données?
    • Reportez-vous à msdn "Lorsque vous créez une contrainte de CLÉ PRIMAIRE, d'un index cluster unique sur la ou les colonnes est automatiquement créé le si un index cluster sur la table n'existe pas", ce qui signifie qu'il n'est pas nécessaire d'être de la même colonne.
    • ce n'est pas le cas. SQL Server n'est certainement pas à garantir que tous les fichiers de données sont disposées dans une zone contiguë de physique de la zone de disque et il y a zéro du système de fichiers de la fragmentation. Il n'est même pas vrai qu'un index cluster est en ordre dans le fichier de données. La mesure dans laquelle ce n'est pas le cas, c'est le degré de fragmentation logique.
    • J'ai un index avec une très grande fragmentation de 98% - qu'est-ce que l'action recommandée - l'entretien régulier?
    • Juste un commentaire rapide pour sauvegarder Martin Smith point d'index en cluster ne garantit pas séquentielle de stockage sur le disque. La gestion de exactement où les données sont placées sur le disque est le travail de l'OS, pas le SGBD. Mais il suggère que les articles sont classés généralement en fonction de la clé de cluster. Ce que cela signifie, c'est que si le DB augmente de 10 go, par exemple, l'OS peut décider de mettre que 10 go 5x2GB morceaux sur les différentes parties du disque. Un cluster tableau couvrant les 10 GO seront stockées séquentiellement sur chaque morceau de 2 go, ces morceaux de 2 go ne PEUVENT PAS être séquentielle cependant.
    • Je sais que c'est tard, mais cette vidéo donne une belle interface graphique explication. youtube.com/watch?v=ITcOiLSfVJQ
    • Quiconque lit cette réponse doit défiler vers le bas pour @Martin Smith répondre et de voir pourquoi affirmant que With a clustered index, the rows are stored physically on the disk in the same order as the index est tout simplement faux.
    • Ok l'idée est relativement clair, mais quand à la non index cluster?
    • Euh, pourquoi il est généralement plus rapide à lire à partir d'un index cluster si vous voulez récupérer toutes les colonnes ? Peut-être que tu voulais dire tous les rangs ?
    • Downvoted pour confus et imprécis de l'utilisation de "physiquement sur le disque".

    InformationsquelleAutor Shiraz Bhaiji
  2. 568

    Un index cluster signifie que vous demandez à la base de données pour stocker des valeurs proches proche l'un de l'autre sur le disque. Cela a l'avantage rapide de l'analyse et de l'extraction d'enregistrements de tomber dans une certaine gamme de cluster valeurs de l'indice.

    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 en particulier, vous pouvez créer un index cluster sur le "code client" de la colonne de la table de l'Ordre. De cette façon, les enregistrements avec le même code client seront stockées physiquement proches les uns des autres sur le disque (cluster) qui accélère leur récupération.

    P. S. L'indice sur le code client sera évidemment pas unique, il faut donc ajouter un deuxième champ "uniquify" de l'index ou de laisser la base de données gérer pour vous, mais c'est une autre histoire.

    Concernant l'utilisation de plusieurs indices. Vous ne pouvez avoir qu'un index cluster par table, car elle définit comment les données sont physiquement arrangé. Si vous voulez une analogie, imaginez une grande salle avec de nombreux tableaux en elle. Vous pouvez soit mettre ces tables pour former plusieurs lignes ou de les tirer tous ensemble pour former une grande table de conférence, mais pas les deux à la fois. Une table peut avoir d'autres indices, puis pointez sur les entrées de l'index cluster, qui à son tour va enfin dire où trouver les données réelles.

    • Cela étant dit CI devraient toujours être utilisées pour PK
    • Donc, avec un index cluster est-il l'enregistre dans l'index ou la table qui sont stockés à proximité ensemble?
    • tableau. L'indice est commandé par définition. Par exemple, un arbre serait ordonnées de façon à ce que l'on peut tout simplement l'adresse de l'arithmétique à la recherche. L'idée du cluster est de répondre à la table de la performance d'un indice donné. Pour être clair, les enregistrements de la table seront réorganisées afin de correspondre à l'ordre que l'indice est à l'origine de.
    • Pas du tout! En effet, la documentation et le nom lui-même sont tout à fait trompeur. Avoir un "index cluster" a vraiment très peu à voir avec l'index. Sur le plan conceptuel, ce que vous avez vraiment est "une table en cluster sur les index x".
    • un deuxième champ «uniquify» l'indice peut être une date et une heure?
    • Bien sûr, vous pouvez utiliser presque n'importe qui est stocké en ligne, donc pas de XML, VARCHAR(MAX), ou VARBINARY(MAX). Notez qu'il est souvent logique de cluster sur le champ de la date premier, comme un index cluster est la plus efficace pour l'analyse de la plage, qui sont les plus courantes sur les types date. YMMV.
    • Cette phrase m'a vendu le concept en une seconde! merci "Si vous voulez récupérer rapidement toutes les commandes d'un client en particulier, vous pouvez créer un index cluster sur le "code client" de la colonne de la table de l'Ordre ...... stockées physiquement proches les uns des autres sur le disque (cluster) qui accélère leur recherche."

    InformationsquelleAutor
  3. 275

    Dans SQL Server ligne orientée de stockage de cluster et les index non-cluster sont organisés comme des B des arbres.

    Ce n'Cluster et Non de l'index cluster signifie réellement?

    (Source De L'Image)

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

    1. Les lignes de l'index cluster de feuilles de pages contient toujours quelque chose pour chacune (non fragmentée) colonnes de la table (soit la valeur, ou un pointeur vers la valeur réelle).
    2. L'index cluster est la copie primaire d'une table.

    Non clustered index peut également faire le point 1 à l'aide de la INCLUDE de l'alinéa (Depuis SQL Server 2005) pour inclure explicitement tous les non colonnes de clé, mais ils sont secondaires à des représentations et il existe toujours une copie des données autour de (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 à peu près identiques. Avec le niveau supérieur de l'indice de pages contenant des valeurs pour les colonnes de clé A,B et le niveau de la feuille de pages contenant A,B,C,D

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

    La citation ci-dessus à partir de SQL Server books online provoque beaucoup de confusion

    À mon avis, il serait beaucoup mieux rédigé comme.

    Il ne peut être qu'un index cluster par le tableau, parce que le niveau de la feuille lignes de l'index cluster sont les lignes de la table.

    Les livres de devis en ligne n'est pas incorrect, mais vous devriez être clair que le "tri" des fois non en cluster et le cluster indices est logique de ne pas physique. Si vous lisez les pages au niveau des feuilles par la suite de la liste, et de lire les lignes de la page dans la fente de la matrice de commande, puis de vous lire les lignes de l'index dans l'ordre de tri mais physiquement les pages ne peuvent pas être triés. L'idée communément admise qu'avec un index cluster les lignes sont toujours stockées physiquement sur le disque dans le même ordre que celui de l'indice de clé est faux.

    Ce serait absurde de mise en œuvre. Par exemple, si une ligne est insérée dans le milieu de 4 go de table SQL Server ne pas avez qu'à copier 2 go de données dans le fichier pour faire de la place pour la nouvelle ligne .

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

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

    Lorsqu'une page de scission se produit une nouvelle page est attribuée à partir de n'importe où dans le groupe de fichiers (soit à partir d'une extension mixte, pour les petites tables, ou un non vide uniforme de mesure appartenant à cet objet ou un nouvellement allouée uniforme de la mesure). Ce pourrait même ne pas être dans le même fichier si le fichier de groupe contient plus d'un.

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

    Dans une base de données nouvellement créée avec un seul fichier, j'ai couru le suivant.

    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

    Ensuite 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

    Résultats étaient tous sur la place. La première ligne dans l'ordre des clés (de valeur 1 - mise en évidence avec la flèche ci-dessous) était presque la dernière page physique.

    Ce n'Cluster et Non de l'index cluster signifie réellement?

    La Fragmentation peut être réduite ou supprimée par la reconstruction ou la réorganisation d'un index à l'augmentation de la corrélation entre l'ordre logique et l'ordre physique.

    Après l'exécution de

    ALTER INDEX ix ON T REBUILD;

    J'ai eu la suivante

    Ce n'Cluster et Non de l'index cluster signifie réellement?

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

    Non index cluster peut être construit sur un segment ou d'un index cluster. Ils contiennent toujours un localisateur de ligne dans la table de base. Dans le cas d'un segment de mémoire c'est une physique de l'identificateur de ligne (rid) et se compose de trois éléments (Fichier:Page:Fente). Dans le cas d'un index Cluster le localisateur de ligne est logique (la clé d'index cluster).

    Pour le dernier cas, si le non l'index cluster déjà, bien entendu, de la CI de la colonne de clé(s) soit NCI colonnes de clé ou INCLUDE-d colonnes, alors que rien n'est ajouté. Sinon, le manque de CI de la colonne de clé(s) silencieusement ajouté à la NCI.

    SQL Server vérifie toujours que les colonnes de clés sont uniques pour les deux types d'index. Le mécanisme qui est appliquée pour les index non déclarées comme unique diffère entre les deux types d'index cependant.

    Index cluster obtenir un uniquifier ajoutée pour toutes les lignes avec des valeurs de clés en double, une ligne existante. C'est juste un ascendant entier.

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

    Le cluster vs non cluster nomenclature est également utilisé pour la colonne de stocker les index. Le papier Les améliorations apportées à SQL Server Colonne Magasins états

    Bien que la colonne de stocker des données n'est pas vraiment "cluster" sur n'importe quelle touche, nous
    décidé de conserver le traditionnel SQL Server convention de référence
    à l'index primaire comme un index cluster.

    • Bien que votre explication pour With a clustered index the rows are stored physically on the disk in the same order as the index est une fausse déclaration est convaincante, presque tous les articles/blogs/administrateurs de base de données prétendent que dans les index cluster, les lignes sont physiquement triés et stockés de manière contiguë
    • oui je suis au courant de cela. C'est sûrement à cause de la formulation sur cette page MSDN mais de voir que le phrasé, il est quelque peu trompeur, vous avez juste besoin de regarder les la fragmentation des sujets
    • Il est incroyable de voir comment certaines fausses déclarations se répète comme parole d'évangile. Un cluster indique que, au moins du point de vue de la lecture séquentielle, il serait "souhaitable" que les lignes stockées physiquement sur le disque dans le même ordre que l'index, mais c'est bien loin de dire qu'il fera effectivement être stockées dans une telle mode.
    • J'ai reproduit et a confirmé les résultats de votre test sur SQL Server 2014. Je reçois 95% la fragmentation de l'indice après la première insertion. Après index rebuild la fragmentation est 0% et les valeurs ont été commandés. Je me demande, peut-on dire que The only time the data rows in a table are stored in sorted order is when its clustered index fragmentation is 0?
    • La Fragmentation couvre également la contiguïté, mais, fondamentalement, oui.
    • Bonne explication, la partie visuelle aidé à la compréhension ! Juste une question, à l'horizontale, les chiffres de la page de droite ? Afin de fermer les numéros de page sont pour le registre de la meilleure ?
    • oui, les séries horizontales sont à la page et le vertical, la clé de l'index. Le second graphique est tout à fait différent des numéros de page montrant la reconstruction d'une zone plus loin dans le fichier. Parfaitement non fragmenté index de l'utilisation des pages contiguës dans l'ordre des clés. La deuxième graphique est assez proche.
    • peut-être longue question,mais il m'a aidé à comprendre la fragmentation,quand j'utilise les résultats spatiale comme mentionné ,je ne suis pas en mesure de voir les points comme indiqué dans votre image,pouvez-vous s'il vous plaît aider à comprendre ?
    • Vous devrez peut-être augmenter le nombre de 1 dans STBuffer(1) si les pages de couvrir un éventail beaucoup plus large que dans mon exemple.
    • Merci Martin,vont essayer de
    • Et vous pourriez avoir besoin de le renforcer par beaucoup. Même à des milliers de dollars en fonction de la distance qui sépare les numéros de page sont. par exemple, i.stack.imgur.com/SPtUD.png. De sorte qu'il pourrait être amélioré par l'application d'un facteur d'échelle de sorte que les axes X et Y sont deux 1-100 basé sur le min et max des valeurs réelles.
    • Maintenant, Monsieur, c'est une réponse. J'adorerais le voir en haut de la liste des réponses mais que va DONC, "rapide et simple" obtient le upvoting.
    • Merci. Cette réponse est 5 ans plus jeune que certains sur cette page qui n'a pas aidé le positionnement.
    • Apprécions que vous avez fourni les graphismes et la commande pour reconstruire l'index.
    • C'est une excellente réponse, mais la question précisément dit "en clair". Pour moi, cela implique qu'ils ont été, après un niveau élevé explication décrit tout simplement (comme le haut réponse est).
    • cette réponse a été donnée 5 ans après que la question initiale a été posée. Le but de cela est de corriger certains aspects trompeurs de ces réponses. Le (8 ans), les caprices de l'OP ne sont pas une source de préoccupation. D'autres lecteurs peuvent apprécier une baisse du niveau de la vue.
    • Oh mon dieu, que sys.fn_PhysLocCracker fonction est génial pour visualiser ce que l'enfer qui se passe!
    • C'est une très bonne explication qui fait beaucoup de sens. Merci bro pour ce morceau de l'information. Que l'on doit être marqué comme réponse correcte, comme celle qui est marquée contient de faux statemements.

    InformationsquelleAutor Martin Smith
  4. 125

    Je réalise que c'est une très vieille question, mais j'ai pensé que je voudrais proposer une analogie pour illustrer l'amende réponses ci-dessus.

    INDEX CLUSTER

    Si vous entrez dans une bibliothèque publique, vous trouverez que les livres sont tous disposés dans un ordre particulier (le plus probable de la classification Décimale de Dewey, ou DDS). Cela correspond à la "index cluster" des livres. Si la DDS# pour le livre que vous voulez a été 005.7565 F736s, vous commencez par localiser la rangée d'étagères qui est marqué 001-099 ou quelque chose comme ça. (Ce bouchon signe à la fin de la pile correspond à un "intermédiaire nœud" dans l'index.) Finalement, vous percez de l'étagère étiquetés 005.7450 - 005.7600, puis numériser jusqu'à ce que vous avez trouvé le livre avec le DDS#, et à ce point vous avez trouvé votre livre.

    INDEX NON-CLUSTER

    Mais si vous n'êtes pas venu dans la bibliothèque avec le DDS# de votre livre mémorisé, alors vous auriez besoin d'un deuxième indice pour vous aider. Dans les temps anciens que vous trouverez à l'avant de la bibliothèque, un magnifique bureau à tiroirs connu comme le "Catalogue". Il avait des milliers de 3x5 cartes, une pour chaque livre, triés dans l'ordre alphabétique (par titre, par exemple). Cela correspond à la "index non-cluster". Ces catalogues ont été organisés dans une structure hiérarchique, de sorte que chaque tiroir sera étiqueté avec le nombre de cartes qu'il contenait (Ka - Kl, par exemple; c'est à dire, le "nœud intermédiaire"). Une fois de plus, vous percez dans jusqu'à ce que vous avez trouvé votre livre, mais dans ce cas, une fois que vous avez trouvé (j'.e, la "feuille"), vous n'avez pas le livre lui-même, mais juste une carte avec un indice nombre (DDS#) avec lequel vous pouvez trouver le livre dans l'index cluster.

    Bien sûr, rien ne pourrait empêcher le bibliothécaire de la photocopie de toutes les cartes et de les trier dans un ordre différent dans une carte séparée catalogue. (Généralement, il y avait au moins deux de ces catalogues: une triés par nom d'auteur, et un par titre.) En principe, vous pourriez avoir autant de ces "non-cluster" indices que vous le souhaitez.

    • Je pourrais, peut-être, de prolonger cette analogie pour décrire "Inclus" colonnes, qui peut être utilisé avec les Index Non Cluster: On pourrait imaginer une carte dans le catalogue de cartes, y compris plus qu'un seul livre, mais au lieu d'un liste de toutes les versions publiées du livre, organisé numériquement par date de publication. Tout comme dans un "inclus colonne" cette information est stockée au niveau de la feuille et ainsi de réduire le nombre de cartes, le bibliothécaire doit créer).
    • C'est vraiment une belle analogie visuelle, thx!
    • La meilleure analogie sur la page. je vous remercie.
    • C'est la meilleure description de cluster et non index cluster.
    • C'est la façon dont aha aha.
    InformationsquelleAutor kmote
  5. 68

    Trouverez ci-dessous quelques caractéristiques de cluster et les index non cluster:

    Index Cluster

    1. Index en cluster sont des indices qui identifient les lignes dans une table SQL.
    2. Chaque table peut avoir exactement un index cluster.
    3. Vous pouvez créer un index cluster qui couvre plus d'une colonne. Par exemple: create Index index_name(col1, col2, col.....).
    4. Par défaut, une colonne de clé primaire a déjà un index cluster.

    Index Non cluster

    1. Index Non cluster sont comme de simples indices. Ils sont juste utilisés pour une récupération rapide des données. Pas sûr d'avoir des données uniques.
    • Une légère correction au Point 1. Un index cluster n' pas nécessairement identifier de manière unique les lignes dans une table SQL. C'est la fonction d'une CLÉ PRIMAIRE
    • une CLÉ PRIMAIRE ou un INDEX UNIQUE?
    InformationsquelleAutor Anirudh Sood
  6. 47

    Très simple, non-technique de règle-de-pouce serait que les index en cluster sont généralement utilisés pour votre clé primaire (ou, au moins, une colonne unique) et que la non-cluster sont utilisés pour d'autres situations (peut-être une clé étrangère). En effet, SQL Server par défaut, créez un index cluster sur votre colonne de la clé primaire(s). Comme vous l'avez appris, l'index cluster se rapporte à la façon dont les données sont physiquement triés sur le disque, ce qui signifie que c'est une bonne tout autour de choix pour la plupart des situations.

    InformationsquelleAutor Dan Diplo
  7. 27

    Index Cluster

    Un index cluster de déterminer l'ordre physique des DONNÉES dans une table.Pour cette raison, une table ont seulement 1 index cluster.

    comme "dictionnaire" Pas besoin de tout autre Indice, c'est déjà l'Indice selon les mots

    Index Non-Cluster

    Non index cluster est analogue à un index dans un Livre.Les données sont stocker dans un seul endroit. l'
    l'indice de magasin dans un autre lieu et de l'indice des pointeurs vers l'emplacement de stockage des données.Pour cette raison, une table de plus de 1 index non-Cluster.

    comme "la Chimie du livre" à regarder il y a un index séparé pour point de Chapitre emplacement et À la "FIN" il y a un autre Indice pointant les MOTS communs emplacement

    • C'est une belle description de visualiser la différence de mieux, merci!
    • belle explication
    InformationsquelleAutor abdul rehman kk
  8. 4

    Index Cluster

    Index cluster de trier et de stocker les données des lignes dans la table ou la vue en fonction de leurs valeurs de clé. Ce sont les colonnes incluses dans la définition de l'index. Il ne peut être qu'un index cluster par le tableau, car les lignes de données peuvent être triées dans un seul ordre.

    Le seul moment où les lignes de données dans une table sont stockées dans l'ordre de tri est lorsque le tableau contient un index cluster. Lorsqu'une table est un index cluster, la table est appelé un cluster de la table. Si une table n'a pas d'index cluster, ses lignes de données sont stockés dans une structure non ordonnée appelé un tas.

    Cluster

    Index non-cluster ont une structure distincte de celle des lignes de données. Un index non-cluster contient la clé d'index non cluster valeurs et chaque valeur de la clé d'entrée est un pointeur vers la ligne de données qui contient la valeur de la clé.
    Le pointeur à partir d'un indice de ligne dans un index non cluster pour une ligne de données est appelé un localisateur de ligne. La structure de la localisateur de ligne dépend de savoir si les pages de données sont stockées dans un segment ou d'un cluster de table. Pour un segment, un localisateur de ligne est un pointeur vers la ligne. Pour un cluster de table, le localisateur de ligne est la clé d'index cluster.

    Vous pouvez ajouter des colonnes non-clé au niveau de la feuille de l'index non-cluster de by-pass existantes de la clé d'index limites, et d'exécuter entièrement couverts, indexés, les requêtes. Pour plus d'informations, voir Créer des Index avec des Colonnes Incluses. Pour plus de détails à propos de la clé d'index limites de voir 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

    InformationsquelleAutor marvelTracker
  9. 1

    Index Cluster:
    Contrainte de Clé primaire crée des Index cluster automatiquement si aucun Index cluster existe déjà sur la table. Les données réelles de l'index cluster peuvent être stockées au niveau des feuilles de l'Index.

    Non Clustered Index:
    Les données réelles de non index cluster n'est pas directement trouvé au nœud feuille, au lieu de cela, il doit prendre une étape supplémentaire pour trouver parce qu'il a seulement les valeurs de la ligne locators pointant vers des données réelles.
    Non clustered Index ne peuvent pas être triés selon les index cluster. Il peut y avoir plusieurs non clustered index par table, en fait, ça dépend de la version de sql server que nous utilisons. Fondamentalement, Sql server 2005 permet de 249 Non Index Cluster et pour les versions ci-dessus comme en 2008, en 2016 il permet 999 Non Clustered Index par table.

    InformationsquelleAutor Abhishek Duppati
  10. 1

    Permettez-moi de proposer une définition classique sur le "regroupement d'index", qui est prise de 15.6.1 de Systèmes De Base De Données: Le Livre Complet:

    Nous pourrions également parler de de clustering index, qui sont des indices sur un attribut ou d'attributs tels que l'ensemble de tuples avec une valeur fixe pour la recherche de la clé de cet indice semble à peu près aussi peu de blocs peut les tenir.

    Comprendre la définition, nous allons jeter un oeil à l'Exemple 15.10 fournis par le manuel:

    Une relation R(a,b) qui est triés sur attribut a et stockée dans ce
    l'ordre, emballés dans des blocs, est sûrement clusterd. Un index sur a est un
    clustering indice, puisque, pour un a-valeur de a1, tous les tuples avec
    cette valeur pour a sont consécutifs. Ils apparaissent ainsi emballé dans
    blocs, execept peut-être pour la première et la dernière des blocs qui contiennent des
    a-valeur de a1, comme suggéré dans la Fig.15.14. Toutefois, un indice sur b est
    peu de chances d'être clustering, depuis les tuples avec une fixe b-valeur
    seront répartis sur tout le fichier, sauf si les valeurs de a et b sont
    très étroitement corrélés.

    Ce n'Cluster et Non de l'index cluster signifie réellement?

    Noter que la définition ne fait pas respecter les blocs de données doivent être contigus sur le disque; il est dit que les tuples avec la clé de recherche sont emballés dans quelques blocs de données que possible.

    Un concept connexe est cluster rapport. Une relation est "cluster" si son les tuples sont emballés dans à peu près ce que quelques blocs peuvent éventuellement tenir ceux des n-uplets. En d'autres termes, à partir d'un bloc de disque perspective, si elle contient des tuples à partir de différentes relations, ces relations ne peuvent pas être regroupés (c'est à dire, il y a plus emballé façon de stocker une telle relation par permutation des n-uplets de la relation à partir d'autres blocs de disque avec les tuples de la n'appartient pas à la relation dans l'actuel bloc de disque). Clairement, R(a,b) dans l'exemple ci-dessus est mis en cluster.

    Pour relier deux concepts, un cluster relation peut avoir un regroupement d'index et de nonclustering index. Cependant, pour les non-cluster rapport, le regroupement des index n'est pas possible, sauf si l'index est construit sur le haut de la clé primaire de la relation.

    "Cluster", un mot est spammé à travers tous les niveaux d'abstraction de base de données de stockage de côté (les trois niveaux d'abstraction: les tuples, les blocs, fichier). Un concept appelé "de fichiers en cluster", qui décrit si un fichier (une abstraction pour un groupe de blocs (un ou plusieurs blocs de disque)) contient les tuples d'une relation ou d'autres relations. Il ne se rapportent pas à l'agrégation de l'indice de concept, comme il est sur au niveau du fichier.

    Cependant, certains matériel pour l'enseignement aime les définir de clustering indice basé sur le cluster du fichier de définition. Ces deux types de définitions sont les mêmes sur cluster niveau de la relation, peu importe si elles définissent cluster relation en termes de données bloc de disque ou de fichier. À partir du lien dans ce paragraphe,

    Un index sur l'attribut(s) sur un fichier est un regroupement d'index quand: Tous les tuples avec une valeur d'attribut d'Un = un sont stockées de manière séquentielle (= consécutivement) dans le fichier de données

    Stockage des tuples consécutivement est la même chose que de dire "les tuples sont emballés dans à peu près ce que quelques blocs peuvent éventuellement tenir les tuples" (avec une petite différence sur l'un parle de fichier, les autres parler de disque). C'est parce que le stockage de tuple consécutivement est le moyen de parvenir "emballé dans à peu près ce que quelques blocs peuvent éventuellement tenir les tuples".

    InformationsquelleAutor xxks-kkk