Heap-lagring har intet at gøre med disse dynger .
Heap betyder blot, at poster i sig selv ikke er bestilt (dvs. ikke knyttet til hinanden).
Når du indsætter en post, bliver den bare indsat i den ledige plads, databasen finder.
Opdatering af en række i en heap-baseret tabel påvirker ikke andre poster (selvom det påvirker sekundære indekser)
Hvis du opretter et sekundært indeks på en HEAP tabel, RID (en slags fysisk pointer til lagerpladsen) bruges som en rækkemarkør.
Clustered index betyder, at posterne er en del af et B-Tree . Når du indsætter en post, vises B-Tree skal linkes igen.
Opdatering af en række i en klynget tabel forårsager genbinding af B-træet, dvs. e. opdatering af interne pointere i andre poster.
Hvis du opretter et sekundært indeks på en klynget tabel, bruges værdien af den klyngede indeksnøgle som en rækkemarkør.
Dette betyder, at et klynget indeks skal være unikt. Hvis et klynget indeks ikke er unikt, en speciel skjult kolonne kaldet uniquifier er tilføjet til indeksnøglen, der gør, at hvis er unikt (og større i størrelse).
Det er også værd at bemærke, at oprettelse af et sekundært indeks på en kolonne gør, at værdierne eller det klyngede indekss nøgle er en del af det sekundære indekss nøgle.
Ved at oprette et indeks på en klynget tabel får du faktisk altid et sammensat indeks
CREATE UNIQUE CLUSTERED INDEX CX_mytable_1234 (col1, col2, col3, col4)
CREATE INDEX IX_mytable_5678 (col5, col6, col7, col8)
Indeks IX_mytable_5678 er faktisk et indeks på følgende kolonner:
col5
col6
col7
col8
col1
col2
col3
col4
Dette har endnu en bivirkning:
En DESC betingelse i et enkelt-kolonne indeks på en klynget tabel giver mening i SQL Server
Dette indeks:
CREATE INDEX IX_mytable ON mytable (col1)
kan bruges i en forespørgsel som denne:
SELECT TOP 100 *
FROM mytable
ORDER BY
col1, id
, mens denne:
CREATE INDEX IX_mytable ON mytable (col1 DESC)
kan bruges i en forespørgsel som denne:
SELECT TOP 100 *
FROM mytable
ORDER BY
col1, id DESC