Bestellen op id gebruikt waarschijnlijk een geclusterde indexscan tijdens het bestellen op datetime gebruikt sortering of index opzoeken.
Beide methoden zijn langzamer dan een geclusterde indexscan.
Als uw tabel is geclusterd op id , in feite betekent dit dat het al is gesorteerd. De records zijn opgenomen in een B+Tree die een gelinkte lijst heeft die de pagina's in id . linkt bestellen. De engine moet gewoon de gekoppelde lijst doorkruisen om de records te krijgen die zijn geordend op id .
Als de id s zijn in sequentiële volgorde ingevoegd, dit betekent dat de fysieke volgorde van de rijen overeenkomt met de logische volgorde en dat de geclusterde indexscan nog sneller zal zijn.
Als u wilt dat uw records op datetime zijn besteld , zijn er twee opties:
- Neem alle records uit de tabel en sorteer ze. Traagheid is duidelijk.
- Gebruik de index op
datetime. De index wordt opgeslagen in een aparte ruimte op de schijf, dit betekent dat de engine in een geneste lus moet pendelen tussen de indexpagina's en tabelpagina's. Het is ook langzamer.
Om de volgorde te verbeteren, kunt u een aparte dekkingsindex maken op datetime :
CREATE INDEX ix_mytable_datetime ON mytable (datetime) INCLUDE (field1, field2, …)
, en neem alle kolommen die u in uw zoekopdracht gebruikt op in die index.
Deze index is als een schaduwkopie van uw tabel, maar met gegevens in een andere volgorde gesorteerd.
Dit zal het mogelijk maken om de key lookups te verwijderen (aangezien de index alle data bevat) waardoor bestellen op datetime mogelijk wordt. zo snel als dat op id .
Bijwerken:
Een nieuwe blogpost over dit probleem: