Algoritmen er dokumenteret af SQL Server-folkene her:Hvordan sammenlignes GUID'er i SQL Server 2005? Jeg citerer her (da det er en gammel artikel, der måske er væk for altid om nogle år)
Generelt giver lighedssammenligninger meget mening med unikke identifikatorværdier. Men hvis du oplever, at du har brug for generel bestilling, så kigger du måske på den forkerte datatype og bør overveje forskellige heltalstyper i stedet.
Hvis du efter nøje overvejelse beslutter dig for at bestille på en unik identifikatorkolonne, bliver du måske overrasket over, hvad du får tilbage.
Givet disse to unikke identifikatorværdier:
@g1='55666BEE-B3A0-4BF5-81A7-86FF976E763F' @g2 ='8DD5BCA5-6ABE-4F73-B4B7-393AE6BBB849'
Mange mennesker tror, at @g1 er mindre end @g2, da '55666BEE' bestemt er mindre end '8DD5BCA5'. Det er dog ikke sådan, SQL Server2005 sammenligner unikke identifikatorværdier.
Sammenligningen foretages ved at se på byte "grupper" fra højre til venstre og fra venstre til højre inden for en byte "gruppe". En bytegruppe er det, der er afgrænset af tegnet '-'. Mere teknisk ser vi først på bytes {10 til 15}, derefter {8-9}, derefter {6-7}, derefter {4-5} og til sidst {0 til 3}.
I dette specifikke eksempel vil vi starte med at sammenligne '86FF976E763F' med '393AE6BBB849'. Straks ser vi, at @g2 faktisk er større end @g1.
Bemærk, at i .NET-sprog har Guid-værdier en anden standardsorteringsrækkefølge end i SQL Server. Hvis du finder behovet for at bestille et array eller en liste med Guid ved hjælp af SQL Server-sammenligningssemantik, kan du bruge anarray eller list of SqlGuid i stedet, som implementerer IComparable på en måde, hvilket er i overensstemmelse med SQL Server-semantik.
Plus sorteringen følger bytegrupper endianness (se her:Globalt unikt identifikator). Grupperne 10-15 og 8-9 er gemt som big endian (svarende til Data4 i wikipedia-artiklen), så de sammenlignes som big endian. Andre grupper sammenlignes med lille endian.