Алгоритъмът е документиран от момчетата от SQL Server тук:Как се сравняват GUID в SQL Server 2005? Цитирам тук (тъй като това е стара статия, която може да изчезне завинаги след няколко години)
Като цяло, сравненията на равенството имат много смисъл със стойности на уникални идентификатори. Ако обаче установите, че се нуждаете от общ ред, тогава може да търсите грешен тип данни и вместо това трябва да обмислите различни типове цели числа.
Ако след внимателен обмисляне решите да поръчате на колона с уникален идентификатор, може да бъдете изненадани от това, което получавате обратно.
Като се имат предвид тези две стойности на уникален идентификатор:
@g1='55666BEE-B3A0-4BF5-81A7-86FF976E763F' @g2 ='8DD5BCA5-6ABE-4F73-B4B7-393AE6BBB849'
Много хора смятат, че @g1 е по-малко от @g2, тъй като '55666BEE' със сигурност е по-малък от '8DD5BCA5'. Въпреки това, SQL Server2005 не сравнява стойностите на уникалния идентификатор.
Сравнението се прави чрез разглеждане на байт „групи“ отдясно наляво и отляво надясно в рамките на байтовата „група“. Байтовата група е това, което е разделено със знака '-'. По-технически, първо разглеждаме байтове {10 до 15}, след това {8-9}, след това {6-7}, след това {4-5} и накрая {0 до 3}.
В този конкретен пример ще започнем със сравняване на „86FF976E763F“ с „393AE6BBB849“. Веднага виждаме, че @g2 наистина е по-голямо от @g1.
Имайте предвид, че в .NET езиците стойностите на Guid имат различен ред по подразбиране, отколкото в SQL Server. Ако установите, че е необходимо да поръчате масив или списък от Guid, използвайки семантиката за сравнение на SQL Server, вместо това можете да използвате anarray или списък на SqlGuid, който имплементира IComparable in away, което е в съответствие със семантиката на SQL Server.
Освен това сортирането следва байтовата група от байтове (вижте тук:Глобално уникален идентификатор). Групите 10-15 и 8-9 се съхраняват като голям байт (съответстващ на Data4 в статията в уикипедия), така че те се сравняват като голям байт. Други групи се сравняват с помощта на малък байт.
