Você deve DEFINITIVAMENTE introduzir um substituto INT IDENTITY() chave primária!!INT já oferece potencialmente até 2 bilhões de linhas - isso não é suficiente?

Essa chave primária/chave clusterizada no SQL Server terá até 64 bytes de tamanho (em vez de 4, para um INT) - o que fará com que seu índice clusterizado E todo o seu índice não clusterizado fique inchado além do reconhecimento. Toda a chave de cluster (todas as suas 8 colunas) será incluída em cada página de cada índice não clusterizado nessa tabela - desperdiçando muito e muito espaço, com certeza.

Portanto, em qualquer tabela de índice, você teria até 16 vezes mais entradas com uma chave clusterizada INT substituta - isso significa muito menos E/S, muito menos tempo perdido lendo páginas de índice.

E imagine tentar estabelecer um relacionamento de chave estrangeira com essa tabela... qualquer tabela filha teria que ter todas as 8 colunas de sua chave primária como colunas de chave estrangeira e especifique todas as 8 colunas em cada junção - que pesadelo!

Com 78 milhões de linhas, mesmo alterando a chave de cluster para INT IDENTITY, você economizará até 60 bytes por linha - só isso resultaria em até 4 GByte de espaço em disco (e uso de RAM em seu servidor). E isso nem está começando a calcular a economia nos índices não clusterizados.......

E claro, sim, eu também mudaria o VARCHAR(10) para INT ou BIGINT - se for um número, faça o campo tipo numérico - não adianta deixar em VARCHAR(10), realmente. Mas isso por si só não fará uma grande diferença em termos de velocidade ou desempenho - apenas torna o trabalho com os dados muito mais fácil (não é necessário sempre lançar em tipos numéricos ao, por exemplo, comparar valores e assim por diante).

Marco