SQL Server-hög v.s. klustrade index

Höglagring har ingenting att göra med dessa högar .

Heap betyder bara att själva poster inte är ordnade (dvs. inte länkade till varandra).

När du infogar en post, infogas den bara i det lediga utrymmet som databasen hittar.

Att uppdatera en rad i en heapbaserad tabell påverkar inte andra poster (även om det påverkar sekundära index)

Om du skapar ett sekundärt index på en HEAP tabellen, RID (en slags fysisk pekare till lagringsutrymmet) används som en radpekare.

Klustrat index betyder att posterna är en del av ett B-Tree . När du infogar en post visas B-Tree måste länkas om.

Att uppdatera en rad i en klustrad tabell orsakar återlänkning av B-trädet, dvs. e. uppdatering av interna pekare i andra poster.

Om du skapar ett sekundärt index på en klustrad tabell, används värdet på den klustrade indexnyckeln som en radpekare.

Detta innebär att ett klustrat index bör vara unikt. Om ett klustrat index inte är unikt, en speciell dold kolumn som kallas uniquifier läggs till indexnyckeln som gör om unik (och större i storlek).

Det är också värt att notera att om du skapar ett sekundärt index på en kolumn blir värdena eller det klustrade indexets nyckel en del av sekundärindexets nyckel.

Genom att skapa ett index på en klustrad tabell får du faktiskt alltid ett sammansatt index

CREATE UNIQUE CLUSTERED INDEX CX_mytable_1234 (col1, col2, col3, col4)

CREATE INDEX IX_mytable_5678 (col5, col6, col7, col8)

Index IX_mytable_5678 är i själva verket ett index på följande kolumner:

col5
col6
col7
col8
col1
col2
col3
col4

Detta har ytterligare en bieffekt:

En DESC villkor i ett index med en kolumn på en klustrad tabell är vettigt i SQL Server

Detta index:

CREATE INDEX IX_mytable ON mytable (col1)

kan användas i en fråga som denna:

SELECT  TOP 100 *
FROM    mytable
ORDER BY
       col1, id

, medan den här:

CREATE INDEX IX_mytable ON mytable (col1 DESC)

kan användas i en fråga som denna:

SELECT  TOP 100 *
FROM    mytable
ORDER BY
       col1, id DESC