Bestellung nach id verwendet wahrscheinlich einen Clustered-Index-Scan beim Sortieren nach datetime verwendet entweder Sortierung oder Indexsuche.
Beide Methoden sind langsamer als ein Clustered-Index-Scan.
Wenn Ihre Tabelle nach id gruppiert ist , im Grunde bedeutet es, dass es bereits sortiert ist. Die Datensätze sind in einem B+Tree enthalten die eine verknüpfte Liste hat, die die Seiten in id verknüpft bestellen. Die Engine sollte einfach die verknüpfte Liste durchlaufen, um die nach id geordneten Datensätze zu erhalten .
Wenn die id s in sequenzieller Reihenfolge eingefügt wurden, bedeutet dies, dass die physische Reihenfolge der Zeilen mit der logischen Reihenfolge übereinstimmt und der Clustered-Index-Scan noch schneller ist.
Wenn Sie möchten, dass Ihre Datensätze nach datetime sortiert werden , gibt es zwei Möglichkeiten:
- Nehmen Sie alle Datensätze aus der Tabelle und sortieren Sie sie. Langsamkeit ist offensichtlich.
- Verwenden Sie den Index für
datetime. Der Index wird in einem separaten Bereich der Festplatte gespeichert, das bedeutet, dass die Engine in einer verschachtelten Schleife zwischen den Indexseiten und den Tabellenseiten wechseln muss. Es ist auch langsamer.
Um die Sortierung zu verbessern, können Sie einen separaten überdeckenden Index für datetime erstellen :
CREATE INDEX ix_mytable_datetime ON mytable (datetime) INCLUDE (field1, field2, …)
, und schließen Sie alle Spalten, die Sie in Ihrer Abfrage verwenden, in diesen Index ein.
Dieser Index ist wie eine Schattenkopie Ihrer Tabelle, aber mit Daten, die in einer anderen Reihenfolge sortiert sind.
Dies wird es ermöglichen, die Schlüsselsuchen loszuwerden (da der Index alle Daten enthält), die eine Sortierung nach datetime machen so schnell wie auf id .
Aktualisierung:
Ein neuer Blogbeitrag zu diesem Problem:
