Wat betekenen geclusterde en niet-geclusterde index eigenlijk?

Ik heb een beperkte blootstelling aan DB en heb DB alleen als applicatieprogrammeur gebruikt. Ik wil meer weten over Clustereden Non clustered indexes.
Ik googlede en wat ik vond was:

Een geclusterde index is een speciaal type index dat de weg opnieuw ordent
records in de tabel zijn fysiek
opgeslagen. Daarom kan tafel alleen . hebben
één geclusterde index. De bladknopen
van een geclusterde index de gegevens bevatten
Pagina’s. Een niet-geclusterde index is a
speciaal type index waarin de
logische volgorde van de index niet
overeenkomen met de fysiek opgeslagen volgorde van
de rijen op schijf. De bladknoop van a
niet-geclusterde index bestaat niet uit
de gegevenspagina’s. In plaats daarvan, het blad
nodes bevatten indexrijen.

Wat ik vond in SO was Wat zijn de verschillen tussen een geclusterde en een niet-geclusterde index?.

Kan iemand dit in gewoon Engels uitleggen?


Antwoord 1, autoriteit 100%

Bij een geclusterde index worden de rijen fysiek op de schijf opgeslagen in dezelfde volgorde als de index. Daarom kan er maar één geclusterde index zijn.

Bij een niet-geclusterde index is er een tweede lijst met verwijzingen naar de fysieke rijen. U kunt veel niet-geclusterde indices hebben, hoewel elke nieuwe index de tijd die nodig is om nieuwe records te schrijven, langer zal maken.

Het is over het algemeen sneller om uit een geclusterde index te lezen als u alle kolommen terug wilt krijgen. U hoeft niet eerst naar de index en vervolgens naar de tabel te gaan.

Het schrijven naar een tabel met een geclusterde index kan langzamer zijn als de gegevens opnieuw moeten worden gerangschikt.


Antwoord 2, autoriteit 50%

Een geclusterde index betekent dat u de database vertelt om de nauwe waarden in de buurt van elkaar op de schijf op te slaan. Dit heeft het voordeel van een snelle scan / ophalen van records die in een aantal reeks geclusterde indexwaarden vallen.

U hebt bijvoorbeeld twee tabellen, klant en bestelling:

Customer
----------
ID
Name
Address
Order
----------
ID
CustomerID
Price

Als u snel alle bestellingen van één bepaalde klant wilt ophalen, wilt u mogelijk een geclusterde index maken op de kolom “CustomerID” van de besteltabel. Op deze manier zullen de records met hetzelfde klantid fysiek dicht bij elkaar worden opgeslagen op schijf (geclusterd) die hun ophalen versnelt.

P.S. De index op CustomerID zal uiteraard niet uniek zijn, dus u hoeft ofwel een tweede veld aan te voegen om de index “Unifificificeren” te maken of de database die voor u voor u is, maar dat is een ander verhaal.

over meerdere indexen. U kunt slechts één geclusterde index per tabel hebben, omdat dit definieert hoe de gegevens fysiek worden geregeld. Als je een analogie wenst, stel je voor een grote kamer met veel tafels erin. Je kunt deze tafels zetten om verschillende rijen te vormen of ze allemaal samen te trekken om een ​​grote conferentietafel te vormen, maar niet op beide manieren tegelijkertijd. Een tabel kan andere indexen hebben, ze zullen dan wijzen op de vermeldingen in de geclusterde index die op zijn beurt eindelijk zal zeggen waar de werkelijke gegevens te vinden.


Antwoord 3, Autoriteit 28%

In SQL Server, rij-georiënteerde opslag, worden zowel geclusterde als niet-gespluwe indexen georganiseerd als B-bomen.

(beeldbron )

Het belangrijkste verschil tussen geclusterde indexen en niet-geclusterde indexen is dat het bladniveau van de geclusterde index isde tabel. Dit heeft twee implicaties.

  1. De rijen op de geclusterde indexbladpagina’s bevatten altijd ietsvoor elk van de (niet-sparse) kolommen in de tabel (ofwel de waarde of een verwijzing naar de werkelijke waarde).
  2. De geclusterde index is de primaire kopie van een tabel.

Niet-geclusterde indexen kunnen ook punt 1 doen door de INCLUDE-clausule (sinds SQL Server 2005) te gebruiken om expliciet alle niet-sleutelkolommen op te nemen, maar dit zijn secundaire representaties en er is altijd een andere kopie van de gegevens rond (de tabel zelf).

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)

De twee bovenstaande indexen zullen bijna identiek zijn. Met de indexpagina’s op het hoogste niveau die waarden bevatten voor de sleutelkolommen A, Ben de pagina’s op bladniveau die A, B, C, D

bevatten

Er kan slechts één geclusterde index per tabel zijn, omdat de gegevensrijen
zelf kunnen in slechts één volgorde worden gesorteerd.

Het bovenstaande citaat uit SQL Server-boeken online zorgt voor veel verwarring

Naar mijn mening zou het veel beter geformuleerd kunnen worden als.

Er kan slechts één geclusterde index per tabel zijn omdat de rijen op bladniveau van de geclusterde index de tabelrijen zijn.

Het online citaat van het boek is niet onjuist, maar het moet duidelijk zijn dat het “sorteren” van zowel niet-geclusterde als geclusterde indices logisch is, niet fysiek. Als u de pagina’s op bladniveau leest door de gelinkte lijst te volgen en de rijen op de pagina in slotarray-volgorde leest, dan leest u de indexrijen in gesorteerde volgorde, maar fysiek zijn de pagina’s mogelijk niet gesorteerd. De algemeen aanvaarde opvatting dat bij een geclusterde index de rijen altijd fysiek op de schijf worden opgeslagen in dezelfde volgorde als de index sleutelis onjuist.

Dit zou een absurde implementatie zijn. Als een rij bijvoorbeeld in het midden van een tabel van 4 GB wordt ingevoegd, hoeft SQL Server niet2 GB aan gegevens naar boven in het bestand te kopiëren om ruimte te maken voor de nieuw ingevoegde rij.

In plaats daarvan vindt er een paginasplitsing plaats. Elke pagina op bladniveau van zowel geclusterde als niet-geclusterde indexen heeft het adres (File: Page) van de volgende en vorige pagina in logische volgorde. Deze pagina’s hoeven niet aaneengesloten of op volgorde van sleutels te staan.

bijv. de gekoppelde paginaketen kan 1:2000 <-> 1:157 <-> 1:7053

Als een pagina wordt gesplitst, wordt een nieuwe pagina toegewezen vanaf elke plek in de bestandsgroep (van een gemengd bereik, voor kleine tabellen of een niet-lege uniforme omvang die bij dat object hoort of een nieuw toegewezen uniforme omvang). Dit kan zelfs niet in hetzelfde bestand staan als de bestandsgroep er meer dan één bevat.

De mate waarin de logische volgorde en contiguïteit verschillen van de geïdealiseerde fysieke versie is de mate van logische fragmentatie.

In een nieuw aangemaakte database met een enkel bestand, heb ik het volgende uitgevoerd.

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

Controleer vervolgens de pagina-indeling met

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

De resultaten waren overal. De eerste rij in sleutelvolgorde (met waarde 1 – gemarkeerd met een pijl hieronder) bevond zich op bijna de laatste fysieke pagina.

Fragmentatie kan worden verminderd of verwijderd door een index opnieuw op te bouwen of te reorganiseren om de correlatie tussen logische volgorde en fysieke volgorde te vergroten.

Na het hardlopen

ALTER INDEX ix ON T REBUILD;

Ik heb het volgende

Als de tabel geen geclusterde index heeft, wordt dit een heap genoemd.

Niet-geclusterde indexen kunnen worden gebouwd op een heap- of een geclusterde index. Ze bevatten altijd een rijzoeker terug naar de basistabel. In het geval van een heap is dit een fysieke rij-identificatie (rid) en bestaat uit drie componenten (File:Page: Slot). In het geval van een geclusterde index is de rijzoeker logisch (de geclusterde indexsleutel).

In het laatste geval, als de niet-geclusterde index natuurlijk al de CI-sleutelkolom(men) bevat, hetzij als NCI-sleutelkolommen of als INCLUDE-d-kolommen, wordt er niets toegevoegd. Anders worden de ontbrekende CI-sleutelkolom(men) stilzwijgend toegevoegd aan de NCI.

SQL Server zorgt er altijd voor dat de sleutelkolommen uniek zijn voor beide typen indexen. Het mechanisme waarmee dit wordt afgedwongen voor indexen die niet als uniek zijn gedeclareerd, verschilt echter tussen de twee indextypen.

Geclusterde indexen krijgen een uniquifiertoegevoegd voor alle rijen met sleutelwaarden die een bestaande rij dupliceren. Dit is gewoon een oplopend geheel getal.

Voor niet-geclusterde indexen die niet als uniek zijn gedeclareerd, voegt SQL Server stil de rijzoeker toe aan de niet-geclusterde indexsleutel. Dit geldt voor alle rijen, niet alleen voor de rijen die feitelijk dubbel zijn.

De geclusterde versus niet-geclusterde nomenclatuur wordt ook gebruikt voor kolomopslagindexen. In de paper Verbeteringen aan SQL Server Column Storesstaat

Hoewel kolomopslaggegevens niet echt “geclusterd” zijn op een sleutel, we
besloten om de traditionele SQL Server-conventie van verwijzen te behouden
naar de primaire index als een geclusterde index.


Antwoord 4, autoriteit 14%

Ik realiseer me dat dit een heel oude vraag is, maar ik dacht dat ik een analogie zou aanbieden om de goede antwoorden hierboven te illustreren.

GECLUSTERDE INDEX

Als je een openbare bibliotheek binnenloopt, zul je zien dat de boeken allemaal in een bepaalde volgorde zijn gerangschikt (waarschijnlijk het Dewey Decimal System of DDS). Dit komt overeen met de “geclusterde index”van de boeken. Als de DDS# voor het gewenste boek 005.7565 F736swas, zou je beginnen met het zoeken naar de rij boekenplanken met het label 001-099of iets dergelijks. (Dit eindkapteken aan het einde van de stapel komt overeen met een “tussenliggend knooppunt” in de index.) Uiteindelijk zou je naar de specifieke plank gaan met het label 005.7450 - 005.7600, dan zou je scannen totdat je vond het boek met het opgegeven DDS#, en op dat moment je hebt je boek gevonden.

NIET-GECLUSTERDE INDEX

Maar als je niet naar de bibliotheek kwam met het DDS# van je boek in het geheugen, dan zou je een tweede index nodig hebben om je te helpen. Vroeger vond je aan de voorkant van de bibliotheek een prachtig ladekastje dat bekend staat als de “Kaartencatalogus”. Er zaten duizenden 3×5 kaarten in — één voor elk boek, gesorteerd in alfabetische volgorde (misschien op titel). Dit komt overeen met de “niet-geclusterde index”. Deze kaartencatalogi waren georganiseerd in een hiërarchische structuur, zodat elke lade zou worden gelabeld met de reeks kaarten die erin zat (bijvoorbeeld Ka - Kl; d.w.z. het “tussenliggende knooppunt”). Nogmaals, je zou doorzoeken totdat je je boek hebt gevonden, maar in ditgeval, als je het eenmaal hebt gevonden (dwz het “bladknooppunt”), heb je het boek zelf niet, maar alleen een kaart met een indexnummer (de DDS#) waarmee je het eigenlijke boek in de geclusterde index kon vinden.

Natuurlijk zou niets de bibliothecaris ervan weerhouden om alle kaarten te fotokopiëren en ze in een andere volgorde te sorteren in een aparte kaartencatalogus. (Normaal gesproken waren er ten minste twee van dergelijke catalogi: één gesorteerd op auteursnaam en één op titel.) In principe kunt u zoveel van deze “niet-geclusterde” indexen hebben als u wilt.


Antwoord 5, autoriteit 6%

Hieronder vindt u enkele kenmerken van geclusterde en niet-geclusterde indexen:

Geclusterde indexen

  1. Geclusterde indexen zijn indexen die de rijen in een SQL-tabel op unieke wijze identificeren.
  2. Elke tabel kan precies één geclusterde index hebben.
  3. U kunt een geclusterde index maken die meer dan één kolom beslaat. Bijvoorbeeld: create Index index_name(col1, col2, col.....).
  4. Standaard heeft een kolom met een primaire sleutel al een geclusterde index.

Niet-geclusterde indexen

  1. Niet-geclusterde indexen zijn als eenvoudige indexen. Ze worden alleen gebruikt voor het snel ophalen van gegevens. Weet niet zeker of u over unieke gegevens beschikt.

Antwoord 6, autoriteit 4%

Een heel eenvoudige, niet-technische vuistregel zou zijn dat geclusterde indexen meestal worden gebruikt voor uw primaire sleutel (of in ieder geval een unieke kolom) en dat niet-geclusterde indexen worden gebruikt voor andere situaties (misschien een vreemde sleutel). Inderdaad, SQL Server zal standaard een geclusterde index maken op uw primaire sleutelkolom(men). Zoals u zult hebben geleerd, heeft de geclusterde index betrekking op de manier waarop gegevens fysiek op schijf worden gesorteerd, wat betekent dat het een goede allround keuze is voor de meeste situaties.


Antwoord 7, autoriteit 4%

Geclusterde index

Een geclusterde index bepaalt de fysieke volgorde van DATA in een tabel. Om deze reden heeft een tabel slechts 1 geclusterde index.

  • woordenboek” Geen behoefte aan een andere Index, het is al Index volgens woorden

Niet-geclusterde index

Een niet-geclusterde index is analoog aan een index in een boek. De gegevens worden op één plaats opgeslagen. De
index wordt op een andere plaats opgeslagen en de index heeft verwijzingen naar de opslaglocatie van de gegevens. Om deze reden heeft een tabel meer dan 1 niet-geclusterde index.

  • Chemieboek” bij het staren is er een aparte index om naar de locatie van het hoofdstuk te verwijzen en aan het “END” is er nog een index die de gemeenschappelijke WOORDEN-locatie aangeeft

Antwoord 8

Geclusterde index

Een geclusterde index is in feite een in boomstructuur georganiseerde tabel. In plaats van de records op te slaan in een ongesorteerde Heap-tabelruimte, is de geclusterde index eigenlijk een B+Tree-index met de Leaf Nodes, die zijn geordend op de waarde van de sleutelkolom van de cluster, die de werkelijke tabelrecords opslaat, zoals geïllustreerd door het volgende diagram.

De geclusterde index is de standaard tabelstructuur in SQL Server en MySQL. Terwijl MySQL een verborgen clusterindex toevoegt, zelfs als een tabel geen primaire sleutel heeft, bouwt SQL Server altijd een geclusterde index als een tabel een primaire sleutelkolom heeft. Anders wordt de SQL Server opgeslagen als een heaptabel.

De geclusterde index kan query’s versnellen die records filteren op de geclusterde indexsleutel, zoals de gebruikelijke CRUD-instructies. Aangezien de records zich in de Leaf Nodes bevinden, is er geen extra zoekactie voor extra kolomwaarden bij het zoeken naar records op basis van hun primaire sleutelwaarden.

Bijvoorbeeld bij het uitvoeren van de volgende SQL-query op SQL Server:

SELECT PostId, Title
FROM Post
WHERE PostId = ? 

U kunt zien dat het Uitvoeringsplan een Clustered Index Seek-bewerking gebruikt om de Leaf Node te lokaliseren die de Post-record bevat, en er zijn slechts twee logische leesbewerkingen vereist om de Clustered Index-knooppunten te scannen:

p>

|StmtText                                                                             |
|-------------------------------------------------------------------------------------|
|SELECT PostId, Title FROM Post WHERE PostId = @P0                                    |
|  |--Clustered Index Seek(OBJECT:([high_performance_sql].[dbo].[Post].[PK_Post_Id]), |
|     SEEK:([high_performance_sql].[dbo].[Post].[PostID]=[@P0]) ORDERED FORWARD)      | 
Table 'Post'. Scan count 0, logical reads 2, physical reads 0

Niet-geclusterde index

Aangezien de geclusterde index meestal wordt gemaakt met behulp van de waarden van de primaire sleutelkolom, moet u een secundaire niet-geclusterde index toevoegen als u zoekopdrachten wilt versnellen die een andere kolom gebruiken.

De secundaire index gaat de waarde van de primaire sleutel opslaan in zijn bladknooppunten, zoals geïllustreerd door het volgende diagram:

Dus, als we een secundaire index maken in de kolom Titlevan de tabel Post:

CREATE INDEX IDX_Post_Title on Post (Title)

En we voeren de volgende SQL-query uit:

SELECT PostId, Title
FROM Post
WHERE Title = ? 

We kunnen zien dat een index-zoekoperatie wordt gebruikt om het bladknooppunt in de IDX_Post_Titleindex te vinden die de SQL-queryprojectie kan bieden waarin we geïnteresseerd zijn in:

|StmtText                                                                      |
|------------------------------------------------------------------------------|
|SELECT PostId, Title FROM Post WHERE Title = @P0                              |
|  |--Index Seek(OBJECT:([high_performance_sql].[dbo].[Post].[IDX_Post_Title]),|
|     SEEK:([high_performance_sql].[dbo].[Post].[Title]=[@P0]) ORDERED FORWARD)|
Table 'Post'. Scan count 1, logical reads 2, physical reads 0

Sinds de bijbehorende PostIdPrimaire sleutelkolomwaarde wordt opgeslagen in de IDX_Post_Titlebladknooppunt, deze query heeft geen extra opzoek nodig om de PostRij in de geclusterde index.


Antwoord 9

Clustered Index

Clustered-indexen Sorteer en bewaar de gegevensrijen in de tabel of weergave op basis van hun sleutelwaarden. Dit zijn de kolommen die zijn opgenomen in de indexdefinitie. Er kan slechts één geclusterde index per tabel zijn, omdat de gegevensrijst zelf in slechts één bestelling kunnen worden gesorteerd.

De enige keer dat de gegevensrijen in een tabel zijn opgeslagen in gesorteerde volgorde, is wanneer de tabel een geclusterde index bevat. Wanneer een tabel een geclusterde index heeft, wordt de tabel een geclusterde tafel genoemd. Als een tabel geen geclusterde index heeft, worden de gegevensrijen opgeslagen in een ongeordende structuur die een heap wordt genoemd.

niet-geclusterd

Niet-geclusterde indexen hebben een structuur gescheiden van de gegevensrijen. Een niet-geclusterde index bevat de niet-geclusterde indextoetswaarden en elke toetswaarde-item heeft een aanwijzer op de gegevensrij die de sleutelwaarde bevat.
De aanwijzer van een indexrij in een niet-geclusterde index naar een gegevensrij wordt een rijzoeker genoemd. De structuur van de rijzoeker hangt af van het feit of de gegevenspagina’s in een heap of in een geclusterde tabel zijn opgeslagen. Voor een heap is een rijzoeker een aanwijzer naar de rij. Voor een geclusterde tabel is de rijzoeker de geclusterde indexsleutel.

U kunt niet-sleutelkolommen toevoegen aan het bladniveau van de niet-geclusterde index om bestaande limieten voor indexsleutels te omzeilen en volledig gedekte, geïndexeerde query’s uit te voeren. Zie Indexen maken met opgenomen kolommen voor meer informatie. Voor details over limieten voor indexsleutels, zie Maximumcapaciteitsspecificaties voor SQL Server.

Referentie: https: //docs.microsoft.com/en-us/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-description


Antwoord 10

Laat me een tekstboekdefinitie geven over “clusteringindex”, die is overgenomen uit 15.6.1 van Databasesystemen: het complete boek:

We kunnen ook spreken van clusteringsindexen, dit zijn indexen op een attribuut of attributen zodanig dat alle tuples met een vaste waarde voor de zoeksleutel van deze index op ongeveer zo min mogelijk blokken verschijnen houd ze vast.

Laten we, om de definitie te begrijpen, eens kijken naar voorbeeld 15.10 uit het leerboek:

Een relatie R(a,b)die is gesorteerd op attribuut aen daarin wordt opgeslagen
orde, verpakt in blokken, is zeker geclusterd. Een index op ais a
clustering index, aangezien voor een gegeven a-waarde a1, alle tuples met
die waarde voor azijn opeenvolgend. Ze lijken dus verpakt in
blokken, execept mogelijk voor de eerste en laatste blokken die bevatten
a-value A1, zoals gesuggereerd in Fig. 15.14. Een index op B is echter
Het is onwaarschijnlijk dat ze clusteren, sinds de tuples met een vast b-value
Zal over het hele bestand worden verspreid, tenzij de waarden van aen bzijn
heel nauw gecorreleerd.

Merk op dat de definitie niet afdwingt de datablokken moeten aansluiten op de schijf; Het zegt alleen dat tuples met de zoektoets zijn ingepakt in zo weinig mogelijk gegevensblokken.

Een gerelateerd concept is geclusterde relatie . Een relatie is “geclusterd” als de tuples ongeveer zo weinig blokken zijn verpakt, zoals mogelijk die tuples kunnen vasthouden. Met andere woorden, vanuit een schijfblokperspectief, als het tuples van verschillende relaties bevat, kunnen die relaties niet geclusterd (dat wil zeggen, er is een meer verpakking om de relatie op te slaan door de tuples van die relatie te wekken van andere schijfblokken met de TUPLES De niet behoort tot de relatie in het huidige schijfblok). Het is duidelijk dat R(a,b)in voorbeeld hierboven geclusterd is.

Om twee concepten aan elkaar te verbinden, kan een geclusterde relatie een clustering-index en niet-spluftindex hebben. Voor niet-geclusterde relatie is clusteringindex echter niet mogelijk, tenzij de index bovenop de primaire sleutel van de relatie is gebouwd.

‘Cluster’ als woord wordt verspreid over alle abstractieniveaus van de databaseopslag (drie abstractieniveaus: tupels, blokken, bestand). Een concept genaamd “geclusterd bestand“, dat beschrijft of een bestand (een abstractie voor een groep blokken (een of meer schijfblokken)) tupels van één relatie of verschillende relaties bevat. Het heeft geen betrekking op het concept van de clusteringindex, zoals het op bestandsniveau is.

Echter, sommige lesmateriaaldefinieert graag de clusteringindex op basis van de geclusterde bestandsdefinitie. Die twee soorten definities zijn hetzelfde op geclusterd relatieniveau, ongeacht of ze een geclusterde relatie definiëren in termen van dataschijfblok of bestand. Via de link in deze paragraaf,

Een index op attribuut(en) A op een bestand is een clusteringindex wanneer: Alle tuples met attribuutwaarde A = a opeenvolgend (= opeenvolgend) in het gegevensbestand worden opgeslagen

Tuples achter elkaar opslaan is hetzelfde als zeggen “tupels zijn verpakt in ongeveer zo weinig blokken als mogelijk die tuples kunnen bevatten” (met een klein verschil dat de ene het over bestanden heeft en de andere over de schijf). Het is omdat het opeenvolgend opslaan van tuple de manier is om “verpakt in ongeveer zo weinig blokken als die tupels kunnen bevatten” te bereiken.


Antwoord 11

Geclusterde index:
Primaire sleutelbeperking maakt automatisch een geclusterde index als er al geen geclusterde index in de tabel bestaat. Werkelijke gegevens van geclusterde index kunnen worden opgeslagen op bladniveau van Index.

Niet-geclusterde index:
Werkelijke gegevens van een niet-geclusterde index worden niet direct gevonden op het bladknooppunt, maar het moet een extra stap nemen om te vinden omdat het alleen waarden heeft van rijzoekers die naar werkelijke gegevens wijzen.
Niet-geclusterde index kan niet worden gesorteerd als geclusterde index. Er kunnen meerdere niet-geclusterde indexen per tabel zijn, dit hangt eigenlijk af van de sql-serverversie die we gebruiken. In principe staat Sql-server 2005 249 niet-geclusterde indexen toe en voor bovenstaande versies zoals 2008, 2016 staat het 999 niet-geclusterde indexen per tabel toe.


Antwoord 12

Geclusterde index– Een geclusterde index definieert de volgorde waarin gegevens fysiek in een tabel worden opgeslagen. Tabelgegevens kunnen slechts op een manier worden gesorteerd, daarom kan er slechts één geclusterde index per tabel zijn. In SQL Server creëert de primaire sleutelbeperking automatisch een geclusterde index op die specifieke kolom.

Niet-geclusterde index– Een niet-geclusterde index sorteert de fysieke gegevens in de tabel niet. In feite wordt een niet-geclusterde index op de ene plaats opgeslagen en tabelgegevens op een andere plaats. Dit is vergelijkbaar met een leerboek waarbij de boekinhoud zich op de ene plaats bevindt en de index op een andere. Dit maakt meer dan één niet-geclusterde index per tabel mogelijk. Het is belangrijk om hier te vermelden dat binnen de tabel de gegevens worden gesorteerd op een geclusterde index. Binnen de niet-geclusterde index worden gegevens echter in de opgegeven volgorde opgeslagen. De index bevat kolomwaarden waarop de index is gemaakt en het adres van het record waartoe de kolomwaarde behoort. Wanneer een query wordt uitgevoerd op een kolom waarop de index is gemaakt, gaat de database eerst naar de index en zoekt het adres van de overeenkomstige rij in de tabel. Het gaat dan naar dat rijadres en haalt andere kolomwaarden op. Door deze extra stap zijn niet-geclusterde indexen langzamer dan geclusterde indexen

Verschillen tussen geclusterde en niet-geclusterde index

  1. Er kan slechts één geclusterde index per tabel zijn. U kunt echter
    maak meerdere niet-geclusterde indexen op een enkele tabel.
  2. Geclusterde indexen sorteren alleen tabellen. Daarom consumeren ze niet
    extra berging. Niet-geclusterde indexen worden op een aparte plaats opgeslagen
    van de eigenlijke tafel die meer opslagruimte claimt.
  3. Geclusterde indexen zijn sneller dan niet-geclusterde indexen omdat ze
    er is geen extra opzoekstap nodig.

Raadpleeg voor meer informatie ditartikel.

Other episodes