Jeg har en begrenset eksponering for DB og har bare brukt DB som applikasjonsprogrammerer. Jeg vil vite om Clustered
og Non clustered indexes
.
Jeg googlet og det jeg fant var:
- En gruppert indeks er en spesiell type indeks som omorganiserer måten poster i tabellen er fysisk > lagret. lagret. Derfor kan en tabell bare ha én én gruppert indeks. Bladnodene i en klyngeindeks inneholder dataene. sidene. En ikke-klynget indeks er en en spesiell type indeks der den logiske rekkefølgen på logiske rekkefølgen i indeksen ikke samsvarer med samsvarer med den fysiske lagrede rekkefølgen til radene på disken. Bladnoden i en ikke-gruppert indeks består ikke av datasidene. datasidene. I stedet inneholder inneholder bladnodene indeksrader.
Det jeg fant i SO var https://stackoverflow.com/questions/91688/what-are-the-differencespros-cons-between-clustered-and-non-clustered-indexes.
Kan noen forklare dette i klartekst?
Med en gruppert indeks lagres radene fysisk på disken i samme rekkefølge som indeksen. Derfor kan det bare være én klyngeindeks.
Med en ikke-klynget indeks er det en annen liste som har pekere til de fysiske radene. Du kan ha mange ikke-klyngede indekser, selv om hver nye indeks vil øke tiden det tar å skrive nye poster.
Det er generelt raskere å lese fra en klyngeindeks hvis du ønsker å få tilbake alle kolonnene. Du slipper å gå først til indeksen og deretter til tabellen.
Det kan ta lengre tid å skrive til en tabell med en klyngeindeks hvis det er behov for å omorganisere dataene.
En klyngeindeks betyr at du ber databasen om å lagre verdier som ligger nær hverandre på disken. Dette har den fordelen at du raskt kan skanne/hente ut poster som faller innenfor et visst område av klyngeindeksverdiene.
Du har for eksempel to tabeller, Customer og Order:
Customer
----------
ID
Name
Address
Order
----------
ID
CustomerID
Price
Hvis du raskt ønsker å finne alle bestillingene til én bestemt kunde, kan det være lurt å opprette en klyngeindeks på kolonnen "CustomerID" i Order-tabellen. På denne måten lagres postene med samme CustomerID fysisk i nærheten av hverandre på disken (gruppert), noe som gjør det raskere å finne dem.
P.S. Indeksen på CustomerID vil selvsagt ikke være unik, så du må enten legge til et ekstra felt for å "uniquify" indeksen eller la databasen håndtere det for deg, men det er en annen historie.
Når det gjelder flere indekser. Du kan bare ha én klyngeindeks per tabell fordi den definerer hvordan dataene er fysisk ordnet. Hvis du ønsker en analogi, kan du tenke deg et stort rom med mange tabeller. Du kan enten sette disse tabellene sammen til flere rader eller trekke dem sammen til et stort konferansebord, men ikke begge deler samtidig. En tabell kan ha andre indekser, og de vil da peke på oppføringene i den grupperte indeksen, som i sin tur sier hvor de faktiske dataene finnes.
En veldig enkel, ikke-teknisk tommelfingerregel er at klyngeindekser vanligvis brukes for primærnøkkelen (eller i det minste en unik kolonne), og at ikke-klyngeindekser brukes i andre situasjoner (kanskje en fremmednøkkel). SQL Server oppretter som standard en klyngeindeks for primærnøkkelkolonnen(e). Som du har lært, er den klyngede indeksen knyttet til hvordan data fysisk sorteres på disken, noe som betyr at den er et godt allround-valg i de fleste situasjoner.