Zamawianie według id prawdopodobnie używa klastrowego skanowania indeksu podczas zamawiania według datetime używa sortowania lub wyszukiwania indeksu.
Obie te metody są wolniejsze niż skanowanie indeksu klastrowego.
Jeśli Twoja tabela jest pogrupowana według id , w zasadzie oznacza to, że jest już posortowany. Rekordy są zawarte w B+Tree który ma połączoną listę łączącą strony w id zamówienie. Silnik powinien po prostu przeszukiwać połączoną listę, aby uzyskać rekordy uporządkowane według id .
Jeśli id s zostały wstawione w kolejności sekwencyjnej, co oznacza, że fizyczna kolejność wierszy będzie zgodna z kolejnością logiczną, a skanowanie indeksu klastrowego będzie jeszcze szybsze.
Jeśli chcesz, aby Twoje rekordy były zamawiane przed datetime , są dwie opcje:
- Weź wszystkie rekordy z tabeli i posortuj je. Powolność jest oczywista.
- Użyj indeksu w
datetime. Indeks jest przechowywany w oddzielnej przestrzeni na dysku, co oznacza, że silnik musi przechodzić między stronami indeksu a stronami tabeli w zagnieżdżonej pętli. Jest też wolniejszy.
Aby poprawić kolejność, możesz utworzyć osobny indeks obejmujący datetime :
CREATE INDEX ix_mytable_datetime ON mytable (datetime) INCLUDE (field1, field2, …)
i uwzględnij w tym indeksie wszystkie kolumny użyte w zapytaniu.
Ten indeks jest jak kopia w tle Twojej tabeli, ale z danymi posortowanymi w innej kolejności.
Umożliwi to pozbycie się wyszukiwań kluczy (ponieważ indeks zawiera wszystkie dane), które sprawią, że uporządkowanie według datetime tak szybko jak na id .
Aktualizacja:
Nowy wpis na blogu dotyczący tego problemu:
