Ich stimme Marc und Unkown oben zu ... 6 Indizes im Clustered-Index sind viel zu viele, insbesondere bei einer Tabelle mit nur 14 Spalten. Sie sollten nicht mehr als 3 oder 4 haben, wenn das so wäre, würde ich 1 oder vielleicht 2 sagen. Sie wissen vielleicht, dass der gruppierte Index die eigentliche Tabelle auf der Festplatte ist. Wenn also ein Datensatz eingefügt wird, muss die Datenbank-Engine ihn sortieren und Platzieren Sie es an seinem sortierten, organisierten Ort auf der Festplatte. Nicht gruppierte Indizes sind dies nicht, sie unterstützen Nachschlagetabellen. Meine VLDBs sind auf der Festplatte (CLUSTERED INDEX) gemäß dem 1. Punkt unten angeordnet.
- Reduzieren Sie Ihren gruppierten Index auf 1 oder 2. Die beste Feldauswahl ist die IDENTITÄT (INT), wenn Sie eine haben, oder ein Datumsfeld, in dem die Felder zur Datenbank hinzugefügt werden, oder ein anderes Feld, das ein ist natürliche Art, wie Ihre Daten der Datenbank hinzugefügt werden. Der Punkt ist, dass Sie versuchen, diese Daten am Ende der Tabelle zu halten ... oder sie so auf der Festplatte anordnen, dass Sie die Datensätze am besten (über 90%) lesen können. Dies sorgt dafür, dass keine Reorganisation stattfindet oder dass nur ein einziger Treffer erforderlich ist, um die Daten für das beste Lesen an die richtige Stelle zu bringen. Achten Sie darauf, die entfernten Felder in nicht geclusterte Indizes zu platzieren, damit Sie die Sucheffizienz nicht verlieren. Ich habe NIE mehr als 4 Felder in meine VLDBs eingefügt. Wenn Sie Felder haben, die häufig aktualisiert werden und in Ihrem Clustered-Index enthalten sind, AUTSCH, wird das den Datensatz auf der Festplatte neu organisieren und eine KOSTENLOSE Fragmentierung verursachen.
- Überprüfen Sie den Füllfaktor Ihrer Indizes. Je größer der Füllfaktor (100), desto voller werden die Datenseiten und Indexseiten. In Bezug darauf, wie viele Datensätze Sie haben und wie viele Datensätze Sie einfügen, ändern Sie den Füllfaktor # (+ oder -) Ihrer nicht gruppierten Indizes, um den Füllraum zu berücksichtigen, wenn ein Datensatz eingefügt wird. Wenn Sie Ihren Clustered-Index in ein sequentielles Datenfeld ändern, spielt dies bei einem Clustered-Index keine so große Rolle. Faustregel (IMO), 60-70 Füllfaktor für hohe Schreibvorgänge, 70-90 für mittlere Schreibvorgänge und 90-100 für hohe Lese-/niedrige Schreibvorgänge. Wenn Sie Ihren Füllfaktor auf 70 senken, bedeutet dies, dass für jeweils 100 Datensätze auf einer Seite 70 Datensätze geschrieben werden, wodurch 30 Datensätze für neue oder neu organisierte Datensätze frei bleiben. Nimmt mehr Platz ein, aber es ist besser, jede Nacht zu DEFRAGIEREN (siehe 4 unten)
- Stellen Sie sicher, dass die Statistiken in der Tabelle vorhanden sind. Wenn Sie die Datenbank durchsuchen möchten, um mithilfe von „sp_createstats 'indexonly'“ Statistiken zu erstellen, erstellt SQL Server alle Statistiken für alle Indizes, die die Engine angesammelt hat, da Statistiken erforderlich sind. Lassen Sie das 'indexonly'-Attribut aber nicht weg, sonst fügen Sie Statistiken für jedes Feld hinzu, das wäre dann nicht gut.
- Überprüfen Sie die Tabelle/Indizes mit DBCC SHOWCONTIG, um festzustellen, welche Indizes am stärksten fragmentiert werden. Ich werde hier nicht auf die Details eingehen, Sie müssen nur wissen, dass Sie es tun müssen. Ändern Sie dann basierend auf diesen Informationen den Füllfaktor nach oben oder unten in Bezug auf die Änderungen, die die Indizes erfahren, und wie schnell (im Laufe der Zeit).
- Richten Sie einen Jobplan ein, der online (DBCC INDEXDEFRAG) oder offline (DBCC DBREINDEX) auf einzelne Indizes wirkt, um sie zu defragmentieren. Warnung:Führen Sie DBCC DBREINDEX nicht auf einer so großen Tabelle aus, ohne dass dies während der Wartungszeit geschieht, da dies die Apps zum Absturz bringen wird ... insbesondere auf dem CLUSTERED INDEX. Du wurdest gewarnt. Testen und testen Sie diesen Teil.
- Verwenden Sie die Ausführungspläne, um zu sehen, welche SCANS und FAT PIPES existieren, und passen Sie die Indizes an, dann defragmentieren und schreiben Sie gespeicherte Prozesse neu, um diese Hotspots loszuwerden. Wenn Sie in Ihrem Ausführungsplan ein ROTES Objekt sehen, liegt das daran, dass es keine Statistiken zu diesem Feld gibt. Das ist schlecht. Dieser Schritt ist eher "Kunst als Wissenschaft".
- Führen Sie außerhalb der Spitzenzeiten UPDATE STATISTICS WITH FULLSCAN aus, um dem Abfragemodul so viele Informationen wie möglich über die Datenverteilung zu geben. Führen Sie andernfalls das standardmäßige UPDATE STATISTICS (mit standardmäßigem 10 %-Scan) für Tabellen während der Wochentage oder öfter aus, wenn Sie es für Ihre Beobachtungen für richtig halten, um sicherzustellen, dass die Engine mehr Informationen über die Datenverteilungen hat, um die Daten effizient abzurufen.
Tut mir leid, dass es so lang geworden ist, aber es ist extrem wichtig. Ich habe Ihnen hier nur minimale Informationen gegeben, wird aber eine Menge helfen. Es gibt einige Bauchgefühle und Beobachtungen, die in die Strategien einfließen, die von diesen Punkten verwendet werden, die Ihre Zeit und Tests erfordern.
Sie müssen nicht zur Enterprise Edition wechseln. Ich habe es jedoch getan, um die Funktionen zu erhalten, von denen zuvor mit der Partitionierung gesprochen wurde. Aber ich habe es SPEZIELL getan, um viel bessere Multi-Threading-Fähigkeiten mit Suchen und Online-DEFRAGING und -Wartung zu haben ... In der Enterprise-Edition ist es viel besser und freundlicher mit VLDBs. Die Standard Edition kann DBCC INDEXDEFRAG auch nicht mit Online-Datenbanken ausführen.
