Du borde DEFINITIVT introducera ett surrogat INT IDENTITY() primärnyckel!!INT ger dig redan potentiellt upp till 2 miljarder rader - räcker inte det??
Den här primärnyckeln/klustrade nyckeln på SQL Server kommer att vara upp till 64 byte stor (istället för 4, för en INT) - vilket kommer att göra ditt klustrade index OCH allt ditt icke-klustrade index svällt till oigenkännlighet. Hela klustringsnyckeln (alla dina 8 kolumner) kommer att inkluderas på varje enskild sida i varje enskilt icke-klusterat index i den tabellen - vilket garanterat slösar massor och massor av utrymme.
Så på en given indextabell skulle du ha upp till 16 gånger fler poster med en surrogat INT-klustrad nyckel - det betyder mycket mindre I/O, mycket mindre bortkastad tid på att läsa indexsidor.
Och tänk dig bara att försöka etablera en främmande nyckelrelation till den tabellen... alla underordnade tabeller måste ha alla 8 kolumner av din primärnyckel som främmande nyckelkolumner, och ange alla 8 kolumner i varje join - vilken mardröm!!
Med 78 miljoner rader, även om du bara ändrar klustringsnyckeln till INT IDENTITY, kommer du att spara upp till 60 byte per rad - bara det skulle visa sig vara upp till 4 GByte diskutrymme (och RAM-användning på din server). Och det börjar inte ens beräkna besparingarna på de icke-klustrade indexen.......
Och naturligtvis, ja, jag skulle också ändra VARCHAR(10) till INT eller BIGINT - om det är ett tal, gör fälttypen numerisk - ingen idé att lämna den på VARCHAR(10), egentligen. Men det i sig kommer inte att göra någon stor skillnad när det gäller hastighet eller prestanda - det gör bara arbetet med data så mycket enklare (behöver inte alltid använda numeriska typer när man t.ex. jämför värden och så vidare).
Marc