Um GUID de 128 bits (uniqueidentifier ) é obviamente 4x maior que um int de 32 bits chave. No entanto, existem algumas vantagens importantes:

• Sem problemas de "INSERÇÃO DE IDENTIDADE" ao mesclar conteúdo
• Se você usar um valor COMB em vez de NEWSEQUENTIALID(), obterá um timestamp INSERT "gratuito". Você pode até SELECT da chave primária com base em um intervalo de data/hora, se você quiser, com alguns CAST() sofisticados chamadas.
• Eles são globalmente únicos, o que acaba sendo bastante útil de vez em quando.
• Como não há necessidade de rastrear marcas d'água, sua camada BL pode atribuir o valor em vez do SQL Server, eliminando assim a etapa de SELECT scope_identity() para obter a chave primária após uma inserção.
• Se for remotamente possível que você tenha mais de 2 bilhões de registros, será necessário usar bigint (64 bits) em vez de int . Depois de fazer isso, uniqueidentifier é apenas duas vezes maior que um bigint .
• O uso de GUIDs torna mais seguro expor chaves em URLs etc. sem se expor a ataques de "adivinha o ID".
• Entre como o SQL Server carrega páginas do disco e como os processadores agora são principalmente de 64 bits, só porque um número é de 128 bits em vez de 32 não significa que demore 4x mais para comparar. O último teste que vi mostrou que os GUIDs são quase tão rápidos.
• O tamanho do índice depende de quantos colunas estão incluídas. Mesmo que os próprios GUIDs sejam maiores, os 8 ou 12 bytes extras podem ser insignificantes em comparação com as outras colunas no índice.

No final, extrair alguma pequena vantagem de desempenho usando números inteiros pode não valer a pena perder as vantagens de um GUID. Teste-o empiricamente e decida por si mesmo.

Pessoalmente, ainda uso os dois, dependendo da situação, mas o fator decisivo nunca se resumiu ao desempenho no meu caso.