Bestilling efter id bruger sandsynligvis en klynget indeksscanning, mens du bestiller efter datetime bruger enten sortering eller indeksopslag.
Begge disse metoder er langsommere end en klynget indeksscanning.
Hvis din tabel er grupperet efter id , dybest set betyder det, at det allerede er sorteret. Posterne er indeholdt i en B+Tree som har en linket liste, der linker siderne i id bestille. Motoren skal bare krydse den linkede liste for at få posterne ordnet efter id .
Hvis id s blev indsat i sekventiel rækkefølge, betyder det, at den fysiske rækkefølge af rækkerne vil matche den logiske rækkefølge, og den klyngede indeksscanning vil være endnu hurtigere.
Hvis du ønsker, at dine poster skal sorteres efter datetime , er der to muligheder:
- Tag alle poster fra tabellen og sorter dem. Langsomhed er indlysende.
- Brug indekset på
datetime. Indekset er gemt i et separat rum på disken, det betyder, at motoren skal skifte mellem indekssiderne og tabelsiderne i en indlejret løkke. Den er også langsommere.
For at forbedre bestillingen kan du oprette et separat dækkende indeks på datetime :
CREATE INDEX ix_mytable_datetime ON mytable (datetime) INCLUDE (field1, field2, …)
, og medtag alle kolonner, du bruger i din forespørgsel, i det indeks.
Dette indeks er som en skyggekopi af din tabel, men med data sorteret i anden rækkefølge.
Dette vil gøre det muligt at slippe af med nøgleopslag (da indekset indeholder alle data), som vil foretage bestilling efter datetime lige så hurtigt som på id .
Opdatering:
Et nyt blogindlæg om dette problem: