Flera gånger har jag sett och svarat på en fråga om sortering i SQL Server. Frågan har formulerats på olika sätt, men I princip är det samma fråga som ställts:

När jag gör SELECT mot min tabell får jag tillbaka raderna i “fel” ordning, jag lade till rad A först, sen rad B, men SQL Server ger mig rad B före rad A.

Det är en vanlig missuppfattning att SQL Server ger oss rader i någon särskild ordning. Men det kan vi inte på något sätt förvänta oss att SQL Server gör. SQL Server försöker att ge oss det vi frågar om så snabbt som möjligt. Om vi ber om rader genom SELECT * FROM tabell så försöker SQL Server att så snabbt som möjligt ge oss alla rader i tabellen tabell. Om det snabbaste sättet är att ge oss datat I samma ordning som det lades in i tabellen så får vi det i den ordningen. Men om det går snabbare att få raderna på något helt annat sätt så får vi raderna sorterade på ett helt annat sätt. Eller snarare: Vi får alltid raderna osorterade.

Det är ganska vanligt att man använder en IDENTITY-kolumn som primärnyckel i en tabell. Då vet vi att datat på disk fysiskt är sorterat i den ordning det har lagts in I tabellen. Detta eftersom en primärnyckel som default skapar ett klustrat index och ett klustrat index lagras ihop med själva datat för tabellen. Alltså: Klustrat index sorterar själva tabellen istället för att lagras vid sidan om tabellen i ett index-träd.

I diskussionerna om sortering på data från SQL Server brukar klustrat index dyka upp och någon brukar påstå att ett klustrat index garanterar att SQL Server ger oss data I en viss ordning. Men det är också fullständigt fel. Ett klustrat index garanterar ingenting annat än att datat är fysiskt sorterat. Men det har ju ingenting att göra med hur SQL Server hämtar data från en tabell att göra. Om SQL Server hittar ett snabbare sätt att ge oss rader i en tabell än att bara läsa från början till sut så kommer ju SQL Server att göra det.

Alltså: Om vi inte har något klustrat index så är datat i en tabell bara en hög med tabellrader, helt utan inbördes ordning. Det är omöjligt att veta vilken ordning vi kommer att få raderna om vi inte ber SQL Server att sortera raderna med en ORDER BY-klausul. Om det finns ett klustrat index så är raderna prydligt ordnade på disk. Men det är precis lika omöjligt att veta i vilken ordning vi kommer att få raderna om vi inte använder en ORDER BY-klausul.

Jag påmindes om det här ämnet i en diskussion på Ask SQL Server Central idag. Just den diskussionen handlade om hur man kan sortera data vid en INSERT. Men det är egentligen samma sak – frågan bygger på missuppfattningen att SQL Server sorterar data i den ordning raderna lagts till.

Det kan ibland finnas skäl att försöka lägga in rader i en viss ordning – nämligen om det finns ett klustrat index som INTE är en IDENTITY-kolumn, eller en datetime-kolumn med CURRENT_TIMESTAMP som default-värde. Ta till exempel ett personregister. Där skulle jag vilja ha ett klustrat index över efternamn, förnamn. Om jag ska lägga in massor av rader i tabellen så är jag lite intresserad av att försöka lägga in dem i “naturlig ordning”, för att undvika fragmentering av data. Men det är ett helt annat ämne…