Problem
Lassen Sie uns etwas Klarheit schaffen, denn dies ist ein häufiges Problem, ein ernstes Problem für jedes Unternehmen, das SQL Server verwendet.
Dieses Problem und die Notwendigkeit von CREATE CLUSTERED INDEX werden missverstanden.
Einverstanden, dass es besser ist, einen permanenten Clustered Index zu haben, als keinen zu haben. Aber das ist nicht der Punkt, und es wird sowieso zu einer langen Diskussion führen, also lassen wir das beiseite und konzentrieren uns auf die gepostete Frage.
Der Punkt ist, dass Sie eine erhebliche Fragmentierung auf dem Heap haben . Sie nennen es immer wieder eine "Tabelle", aber auf der Ebene der physischen Datenspeicherung oder der Datenstruktur gibt es so etwas nicht. Eine Tabelle ist ein logisches Konzept, kein physisches. Es ist eine Sammlung physischer Datenstrukturen. Die Sammlung ist eine von zwei Möglichkeiten:
-
Haufen
plus alle nicht geclusterten Indizes
plus Text-/Bildketten -
oder ein Clustered Index
(beseitigt den Heap und one Nicht geclusterter Index)
plus alle nicht geclusterten Indizes
plus Text-/Bildketten.
Haufen werden stark fragmentiert; je mehr eingestreute (zufällige) Einfügungen/Löschungen/Aktualisierungen vorhanden sind, desto mehr Fragmentierung.
Es gibt keine Möglichkeit, den Haufen so zu bereinigen, wie er ist. MS bietet keine Möglichkeit (andere Anbieter schon).
Lösung
Wir wissen jedoch, dass Create Clustered Index den Heap komplett neu schreibt und neu ordnet. Die Methode (kein Trick) besteht daher darin, Clustered Index nur zum Zwecke der Defragmentierung des Heaps zu erstellen , und lassen Sie es danach fallen. Sie benötigen freien Speicherplatz in der Datenbank von table_size x 1,25.
Verwenden Sie dabei auf jeden Fall FILLFACTOR, um future zu reduzieren Zersplitterung. Der Heap benötigt dann mehr zugewiesenen Speicherplatz, was zukünftige Einfügungen, Löschungen und Zeilenerweiterungen aufgrund von Aktualisierungen ermöglicht.
Hinweis
-
Beachten Sie, dass es drei Stufen gibt der Fragmentierung; hier geht es nur um Level III, die Fragmentierung innerhalb des Heaps, die durch Mangel an Clustered Index verursacht wird
-
Als separate Aufgabe möchten Sie vielleicht zu einem anderen Zeitpunkt die Implementierung eines permanenten Clustered Index in Betracht ziehen, der die Fragmentierung vollständig eliminiert ... aber das ist etwas anderes als das gepostete Problem.
Antwort auf Kommentar
Nicht ganz. Ich würde es nicht als "Einschränkung" bezeichnen.
-
Die Methode, die ich angegeben habe, um die Fragmentierung im Heap zu beseitigen, besteht darin, einen Clustered Index zu erstellen, und ihn dann zu löschen. Dh. vorübergehend, deren einziger Zweck darin besteht, die Fragmentierung zu korrigieren.
-
Die (permanente) Implementierung eines Clustered Index auf der Tabelle ist eine viel bessere Lösung, weil es insgesamt reduziert Fragmentierung (die Datenstruktur kann immer noch fragmentiert werden, siehe detaillierte Informationen in den Links unten), die weitaus geringer ist als die Fragmentierung, die in einem Heap auftritt.
-
Jede Tabelle in einer relationalen Datenbank (mit Ausnahme von „Pipe“- oder „Queue“-Tabellen) sollte einen Clustered Index haben, um die verschiedenen Vorteile nutzen zu können.
-
Der Clustered-Index sollte sich auf Spalten befinden, die die Daten verteilen (um INSERT-Konflikte zu vermeiden), und niemals auf einer monoton ansteigenden Spalte wie Record ID indexiert werden, was einen INSERT-Hotspot auf der letzten Seite garantiert.
-
In MS SQL und Sybase ASE gibt es drei Ebenen der Fragmentierung und innerhalb jeder Ebene mehrere verschiedene Typen . Denken Sie daran, dass wir uns beim Umgang mit Fragmentierung auf DataStructures konzentrieren müssen, nicht auf Tabellen (eine Tabelle ist eine Sammlung von DataStructures, wie oben erläutert). Die Ebenen sind:
-
Ebene I • Extra-Datenstruktur
Außerhalb der betroffenen Datenstruktur, über oder innerhalb der Datenbank. -
Ebene II • Datenstruktur
Innerhalb der betreffenden Datenstruktur, oberhalb von Seiten (über alle Seiten hinweg)
Dies ist die Ebene, die am häufigsten von DBAs angesprochen wird. -
Ebene III • Seite
Innerhalb der betreffenden Datenstruktur, innerhalb der Seiten
Diese Links enthalten alle Details zur Fragmentierung. Sie sind spezifisch für Sybase ASE, jedoch gelten die Informationen auf struktureller Ebene für MS SQL.
Beachten Sie, dass die Methode, die ich gegeben habe, Stufe II ist, sie korrigiert die Fragmentierung der Stufen II und III.
