Frederik resume bem, e isso é realmente o que Kimberly Tripp também prega:a chave de agrupamento deve ser estável (nunca muda), sempre crescente (IDENTITY INT), pequena e única.

No seu cenário, prefiro colocar a chave de clustering na coluna BIGINT em vez da coluna VARCHAR(80).

Em primeiro lugar, com a coluna BIGINT, é razoavelmente fácil impor exclusividade (se você não impor e garantir a exclusividade, o SQL Server adicionará um "exclusivo" de 4 bytes a cada uma de suas linhas) e é MUITO menor em média que um VARCHAR(80).

Por que o tamanho é tão importante? A chave de cluster também será adicionada a EACH e a cada um de seus índices não clusterizados - portanto, se você tiver muitas linhas e muitos índices não clusterizados, ter 40-80 bytes versus 8 bytes pode rapidamente fazer um ENORME diferença.

Além disso, outra dica de desempenho:para evitar as chamadas pesquisas de favoritos (de um valor em seu índice não clusterizado por meio da chave de clustering nas páginas de folha de dados reais), o SQL Server 2005 introduziu a noção de "colunas incluídas" em seus índices não clusterizados. Esses são extremamente úteis e muitas vezes esquecidos. Se suas consultas geralmente exigem os campos de índice mais apenas um ou dois outros campos do banco de dados, considere incluí-los para obter o que é chamado de "índices de cobertura". Novamente - veja o excelente artigo de Kimberly Tripp - ela é a Deusa da Indexação do SQL Server! :-) e ela pode explicar essas coisas muito melhor do que eu...

Então, para resumir:coloque sua chave de cluster em uma coluna pequena, estável e exclusiva - e você se sairá bem!

Marco