O algoritmo é documentado pelos caras do SQL Server aqui:Como os GUIDs são comparados no SQL Server 2005? Cito aqui (já que é um artigo antigo que pode desaparecer para sempre em alguns anos)
Em geral, as comparações de igualdade fazem muito sentido com valores identificadores exclusivos. No entanto, se você precisar de ordenação geral, poderá estar olhando para o tipo de dados errado e deve considerar vários tipos inteiros.
Se, após uma reflexão cuidadosa, você decidir fazer o pedido em uma coluna identificadora exclusiva, poderá se surpreender com o que receberá de volta.
Dados estes dois valores de identificador único:
@g1='55666BEE-B3A0-4BF5-81A7-86FF976E763F' @g2 ='8DD5BCA5-6ABE-4F73-B4B7-393AE6BBB849'
Muitas pessoas pensam que @g1 é menor que @g2, já que '55666BEE' é certamente menor que '8DD5BCA5'. No entanto, não é assim que o SQL Server2005 compara valores de identificador exclusivo.
A comparação é feita observando os "grupos" de bytes da direita para a esquerda e da esquerda para a direita dentro de um "grupo" de bytes. Um grupo de bytes é o que é delimitado pelo caractere '-'. Mais tecnicamente, examinamos primeiro os bytes {10 a 15}, depois {8-9}, depois {6-7}, depois {4-5} e, por último, {0 a 3}.
Neste exemplo específico, começaríamos comparando '86FF976E763F' com '393AE6BBB849'. Imediatamente vemos que @g2 é realmente maior que @g1.
Observe que em linguagens .NET, os valores Guid têm uma ordem de classificação padrão diferente da do SQL Server. Se você encontrar a necessidade de solicitar uma matriz ou lista de Guid usando a semântica de comparação do SQL Server, poderá usar uma matriz ou lista de SqlGuid, que implementa IComparable de forma consistente com a semântica do SQL Server.
Além disso, a classificação segue a endianidade dos grupos de bytes (veja aqui:Identificador globalmente exclusivo). Os grupos 10-15 e 8-9 são armazenados como big endian (correspondente ao Data4 no artigo da wikipedia), então são comparados como big endian. Outros grupos são comparados usando little endian.
