Dies ist in erster Linie wichtig, wenn es mit zusammengesetzten Indizes verwendet wird:
CREATE INDEX ix_index ON mytable (col1, col2 DESC);
kann verwendet werden für:
SELECT *
FROM mytable
ORDER BY
col1, col2 DESC
oder:
SELECT *
FROM mytable
ORDER BY
col1 DESC, col2
, aber nicht für:
SELECT *
FROM mytable
ORDER BY
col1, col2
Ein Index für eine einzelne Spalte kann auf beide Arten effizient zum Sortieren verwendet werden.
Einzelheiten finden Sie im Artikel in meinem Blog:
- Absteigende Indizes
Aktualisierung:
Tatsächlich kann dies sogar für einen einzelnen Spaltenindex von Bedeutung sein, obwohl es nicht so offensichtlich ist.
Stellen Sie sich einen Index für eine Spalte einer gruppierten Tabelle vor:
CREATE TABLE mytable (
pk INT NOT NULL PRIMARY KEY,
col1 INT NOT NULL
)
CREATE INDEX ix_mytable_col1 ON mytable (col1)
Der Index auf col1 behält geordnete Werte von col1 zusammen mit den Verweisen auf Zeilen.
Da die Tabelle geclustert ist, sind die Verweise auf Zeilen eigentlich die Werte von pk . Sie werden auch innerhalb jedes Werts von col1 geordnet .
Das bedeutet, dass die Blätter des Index tatsächlich auf (col1, pk) geordnet sind , und diese Abfrage:
SELECT col1, pk
FROM mytable
ORDER BY
col1, pk
braucht keine Sortierung.
Wenn wir den Index wie folgt erstellen:
CREATE INDEX ix_mytable_col1_desc ON mytable (col1 DESC)
, dann die Werte von col1 werden absteigend sortiert, aber die Werte von pk innerhalb jedes Werts von col1 werden aufsteigend sortiert.
Das bedeutet, dass die folgende Abfrage:
SELECT col1, pk
FROM mytable
ORDER BY
col1, pk DESC
kann von ix_mytable_col1_desc bereitgestellt werden aber nicht von ix_mytable_col1 .
Mit anderen Worten, die Spalten, die einen CLUSTERED INDEX bilden in jeder Tabelle sind immer die abschließenden Spalten eines anderen Index in dieser Tabelle.
