Vous devriez CERTAINEMENT introduire un substitut INT IDENTITY() clé primaire!!INT vous donne déjà potentiellement jusqu'à 2 milliards de lignes - n'est-ce pas suffisant ??
Cette clé primaire / clé clusterisée sur SQL Server aura une taille maximale de 64 octets (au lieu de 4, pour un INT) - ce qui rendra votre index clusterisé ET tous vos index non clusterisés gonflés au-delà de la reconnaissance. La clé de clustering entière (toutes vos 8 colonnes) sera incluse sur chaque page de chaque index non clusterisé de cette table - gaspillant beaucoup, beaucoup d'espace à coup sûr.
Ainsi, sur une table d'index donnée, vous auriez jusqu'à 16 fois plus d'entrées avec une clé groupée INT de substitution - cela signifie beaucoup moins d'E/S, beaucoup moins de temps perdu à lire les pages d'index.
Et imaginez simplement essayer d'établir une relation de clé étrangère avec cette table... toute table enfant devrait avoir les 8 colonnes de votre clé primaire en tant que colonnes de clé étrangère et spécifiez les 8 colonnes dans chaque jointure - quel cauchemar !!
À 78 millions de lignes, le simple fait de changer la clé de clustering en INT IDENTITY vous fera économiser jusqu'à 60 octets par ligne - cela représenterait à lui seul jusqu'à 4 Go d'espace disque (et l'utilisation de la RAM dans votre serveur). Et ça ne commence même pas à calculer les gains sur les indices non clusterisés......
Et bien sûr, oui, je changerais également le VARCHAR(10) en INT ou BIGINT - si c'est un nombre, rendez le type de champ numérique - inutile de le laisser à VARCHAR(10), vraiment. Mais cela seul ne va pas faire une énorme différence en termes de vitesse ou de performances - cela rend simplement le travail avec les données beaucoup plus facile (vous n'avez pas besoin de toujours utiliser des types numériques lorsque, par exemple, vous comparez des valeurs, etc.).
Marc
