GUIDs são problemáticos como chaves em cluster devido à alta aleatoriedade. Esse problema foi abordado por Paul Randal na última coluna de perguntas e respostas da Technet Magazine:Eu gostaria de usar um GUID como chave de índice clusterizado, mas os outros estão argumentando que isso pode levar a problemas de desempenho com índices. Isso é verdade e, em caso afirmativo, você pode explicar por quê?

Agora, lembre-se de que a discussão é especificamente sobre clustered índices. Você diz que deseja usar a coluna como 'ID', isso não está claro se você quer dizer como chave clusterizada ou apenas chave primária. Normalmente, os dois se sobrepõem, portanto, assumirei que você deseja usá-lo como índice clusterizado. As razões pelas quais essa é uma escolha ruim são explicadas no link para o artigo que mencionei acima.

Para índices não clusterizados, os GUIDs ainda apresentam alguns problemas, mas não tão grandes quanto quando são a chave clusterizada mais à esquerda da tabela. Novamente, a aleatoriedade dos GUIDs introduz divisões e fragmentação de página, seja apenas no nível de índice não clusterizado (um problema muito menor).

Existem muitas lendas urbanas em torno do uso do GUID que os condenam com base em seu tamanho (16 bytes) em comparação com um int (4 bytes) e prometem um desempenho horrível se forem usados. Isso é um pouco exagerado. Uma chave de tamanho 16 ainda pode ser uma chave muito eficiente, em um modelo de dados adequadamente projetado. Embora seja verdade que ser 4 vezes maior que um int resulta em mais páginas não-folha de menor densidade em índices, essa não é uma preocupação real para a grande maioria das tabelas. A estrutura b-tree é uma árvore naturalmente bem equilibrada e a profundidade de passagem de árvore raramente é um problema, portanto, buscar um valor com base na chave GUID em oposição a uma chave INT é semelhante em desempenho. Um percurso de página folha (ou seja, uma varredura de tabela) não examina as páginas não folha, e o impacto do tamanho do GUID no tamanho da página é normalmente muito pequeno, pois o registro em si é significativamente maior do que os 12 bytes extras introduzidos pelo GUID. Então, eu seguiria o conselho de ouvir dizer com base em 'é 16 bytes vs. 4' com um grão de sal bastante grande. Analise caso a caso e decida se o impacto do tamanho faz uma diferença real:quantos outros colunas estão na tabela (ou seja, quanto impacto tem o tamanho do GUID nas páginas de folha) e quantas referências estão usando (ou seja, quantas outros tabelas aumentarão devido ao fato de precisarem armazenar uma chave estrangeira maior).

Estou chamando todos esses detalhes em uma espécie de defesa improvisada dos GUIDs porque eles têm recebido muita má imprensa ultimamente e alguns são imerecidos. Eles têm seus méritos e são indispensáveis ​​em qualquer sistema distribuído (no momento em que você está falando de movimentação de dados, seja via replicação ou estrutura de sincronização ou qualquer outra coisa). Já vi decisões ruins sendo tomadas com base na má reputação do GUID quando foram evitadas sem a devida consideração. Mas é verdade, se você precisar usar um GUID como chave clusterizada, certifique-se de resolver o problema de aleatoriedade:use guids sequenciais quando possivel.

E, finalmente, para responder à sua pergunta:se você não tiver um específico motivo para usar GUIDs, use INTs.