Du bør BESINDT introducere en surrogat INT IDENTITY() primær nøgle!!INT giver dig allerede potentielt op til 2 milliarder rækker - er det ikke nok??
Denne primære nøgle / klyngede nøgle på SQL Server vil være op til 64 bytes i størrelse (i stedet for 4, for en INT) - hvilket vil få dit klyngede indeks OG alt dit ikke-klyngede indeks til at blive oppustet til ukendelighed. Hele klyngingsnøglen (alle dine 8 kolonner) vil blive inkluderet på hver enkelt side i hvert enkelt ikke-klyngede indeks på den tabel - spilder helt sikkert masser af plads.
Så på en given indekstabel ville du have op til 16 gange flere poster med en surrogat INT-klyngenøgle - det betyder meget mindre I/O, meget mindre spildtid på at læse indekssider.
Og forestil dig bare, at du prøver at etablere et fremmednøgleforhold til den tabel.... enhver underordnet tabel skal have alle 8 kolonner af din primære nøgle som fremmednøglekolonner, og angiv alle 8 kolonner i hver join - hvilket mareridt!
Ved 78 millioner rækker vil selv blot at ændre klyngingsnøglen til INT IDENTITY spare dig for op til 60 bytes pr. række - det alene ville vise sig at være op til 4 GByte diskplads (og RAM-forbrug på din server). Og det begynder ikke engang at beregne besparelserne på de ikke-klyngede indeks.......
Og selvfølgelig, ja, jeg ville også ændre VARCHAR(10) til INT eller BIGINT - hvis det er et tal, så gør feltet til numerisk - det giver ingen mening at lade det være på VARCHAR(10), egentlig. Men det alene kommer ikke til at gøre den store forskel med hensyn til hastighed eller ydeevne - det gør bare arbejdet med dataene så meget nemmere (du behøver ikke altid at bruge numeriske typer, når du f.eks. sammenligner værdier og så videre).
Marc