Jeg vil blot indsætte en advarsel:venligst meget forsigtigt vælg dit klyngede indeks! Hver "almindelig" datatabel burde have et klynget indeks, da det at have et klynget indeks faktisk fremskynder en masse operationer - ja, fremskynder , selv indsætter og sletter! Men kun hvis du vælger en vare klynget indeks.
Det er den mest replikerede datastruktur i din SQL Server-database. Klyngerøglen vil også være en del af hvert ikke-klyngede indeks på din tabel.
Du bør være yderst forsigtig, når du vælger en klyngenøgle - det skal være:
-
smal (4 bytes ideel)
-
unik (det er trods alt "rækkemarkøren". Hvis du ikke gør den unik, vil SQL Server gøre det for dig i baggrunden, hvilket koster dig et par bytes for hver indtastning gange antallet af rækker og antallet af ikke-klyngede indekser, du har - det kan være meget dyrt!)
-
statisk (skift aldrig - hvis muligt)
-
ideelt set stadigt stigende så du vil ikke ende med forfærdelig indeksfragmentering (en GUID er det modsatte af en god klyngenøgle - af den særlige grund)
-
den skal være ikke-nulbar og ideelt set også fast bredde - en
varchar(250)laver en meget dårlig klyngenøgle
Alt andet burde virkelig være andet og tredje niveau af betydning bag disse punkter ....
Se nogle af Kimberly Tripps (The Queen of Indexing ) blogindlæg om emnet - alt hvad hun har skrevet på sin blog er helt uvurderligt - læs det, fordøj det - lev efter det!
- GUID'er som PRIMÆRE NØGLER og/eller clustering-nøglen
- The Clustered Index Debatts Continues...
- Stadig voksende klyngenøgle - The Clustered Index Debate...........igen!
- Diskplads er billig - det er ikke pointen!