Das sollten Sie DEFINITIV Führen Sie einen Ersatz INT IDENTITY() ein Primärschlüssel !!INT bietet Ihnen bereits potenziell bis zu 2 Milliarden Zeilen - ist das nicht genug?
Dieser Primärschlüssel/Clustered Key auf SQL Server hat eine Größe von bis zu 64 Bytes (statt 4 für einen INT) - wodurch Ihr Clustered-Index UND Ihr gesamter Non-Clustered-Index bis zur Unkenntlichkeit aufgebläht werden. Der gesamte Clustering-Schlüssel (alle Ihre 8 Spalten) wird auf jeder einzelnen Seite jedes einzelnen nicht geclusterten Indexes in dieser Tabelle enthalten sein - was mit Sicherheit viel, viel Platz verschwendet.
In jeder gegebenen Indextabelle hätten Sie also bis zu 16-mal mehr Einträge mit einem Ersatz-INT-Cluster-Schlüssel – das bedeutet viel weniger I/O, viel weniger Zeitverschwendung beim Lesen von Indexseiten.
Und stellen Sie sich vor, Sie versuchen, eine Fremdschlüsselbeziehung zu dieser Tabelle herzustellen. Jede untergeordnete Tabelle müsste alle 8 Spalten haben Ihres Primärschlüssels als Fremdschlüsselspalten und spezifizieren Sie alle 8 Spalten in jedem Join - was für ein Albtraum!!
Bei 78 Millionen Zeilen sparen Sie sogar bis zu 60 Bytes pro Zeile, wenn Sie nur den Clustering-Schlüssel auf INT IDENTITY ändern - das allein würde bis zu 4 GByte Speicherplatz (und RAM-Nutzung auf Ihrem Server) bedeuten. Und das ist noch nicht einmal der Anfang, um die Einsparungen bei den nicht geclusterten Indizes zu berechnen.......
Und natürlich, ja, ich würde auch VARCHAR(10) in INT oder BIGINT ändern - wenn es eine Zahl ist, machen Sie den Feldtyp numerisch - es hat wirklich keinen Sinn, es bei VARCHAR(10) zu belassen. Aber das allein wird keinen großen Unterschied in Bezug auf Geschwindigkeit oder Leistung machen - es macht das Arbeiten mit den Daten nur viel einfacher (Sie müssen nicht immer auf numerische Typen umsteigen, wenn Sie z. B. Werte vergleichen usw.).
Markus
