Wann sollte ich Indizes neu erstellen?


Antworten:


41

In meiner Antwort gehe ich davon aus, dass Sie regelmäßig einen Indexpflegeprozess durchführen sollten. Bei der Indexpflege sollten jedoch nur die Indizes neu erstellt / organisiert werden, für die dies ausdrücklich erforderlich ist.

Dies wirft die Frage auf: Wann muss ein Index neu erstellt oder organisiert werden? Rolando hat das schön angerührt. Auch hier riskiere ich, extrem breit zu sein. Ein Index muss gewartet werden, wenn der Fragmentierungsgrad die Leistung beeinträchtigt. Dieser Fragmentierungsgrad kann je nach Größe und Zusammensetzung des Index variieren.

Wenn ich für SQL Server spreche, wähle ich in der Regel eine Indexgröße und eine Indexfragmentierungsstufe, ab der ich mit der Indexwartung beginne. Wenn ein Index weniger als 100 Seiten enthält, führe ich keine Wartung durch.

Wenn ein Index zwischen 10% und 30% fragmentiert ist, werde ich REORGANIZEden Index und UPDATEdie Statistik. Wenn ein Index zu mehr als 30% fragmentiert ist, werde ich REBUILDden Index - mit nein UPDATE STATISTICS, da dies von der REBUILD. Beachten Sie jedoch, dass bei einer Neuerstellung nur das Statistikobjekt aktualisiert wird, das direkt mit dem Index verknüpft ist. Andere Spaltenstatistiken müssen separat gepflegt werden.

Diese Antwort ist wirklich nur ein langer Weg zu sagen: Ja, Sie sollten eine routinemäßige Indexpflege durchführen, jedoch nur für die Indizes, die dies benötigen.


19

Wann sollte ich die Indizes in meiner relationalen Datenbank (z. B. SQL Server) neu erstellen?

Sie sollten Indizes neu erstellen, wenn sie durch besondere Ereignisse stark fragmentiert werden. Beispielsweise führen Sie eine große Datenmenge in eine indizierte Tabelle aus.

Gibt es Gründe für die regelmäßige Neuerstellung von Indizes?

Was ist, wenn Ihre Indizes aufgrund regelmäßiger Aktivitäten regelmäßig fragmentiert werden? Sollten Sie regelmäßige Wiederherstellungen einplanen? Wie oft sollten sie rennen?

Tom Kyte empfiehlt in diesem klassischen Ask Tom-Thread :

Die Zeitverzögerung zwischen den Neuerstellungen des Index sollte ungefähr IMMER betragen.

...

Ich weiß nicht, wie ich es besser sagen soll - der Index soll groß und fett sein und über mehr Platz verfügen. Es befindet sich in einer Spalte, die Sie aktualisieren, und verschiebt den Indexeintrag von Ort zu Ort im Index. An einem Tag hat die Zeile den Code "A", am nächsten Tag lautet der Code "G", dann "Z", dann "H" und so weiter. Der Indexeintrag für die Zeile verschiebt sich also von Ort zu Ort im Index. Dabei braucht es Platz - wenn der Platz nicht da ist, teilen wir den Block in zwei Teile - und schaffen Platz. Jetzt wird der Index fett. Im Laufe der Zeit ist der Index 2-3x so groß wie zu Beginn und "halb oder mehr leer". Aber das ist in Ordnung, da Sie Zeilen verschieben. Wenn wir nun die Reihen verschieben, müssen wir keine Blöcke mehr teilen, um Platz zu schaffen - der Raum ist bereits verfügbar.

Dann kommen Sie und erstellen den Index neu oder löschen ihn und erstellen ihn neu (was die gleichen Auswirkungen hat - nur die Neuerstellung ist "sicherer" - hat keine Chance, den Index zu verlieren und kann schneller sein, da der Index von neu erstellt werden kann den vorhandenen Index scannen, anstatt die Tabelle zu scannen und einen neuen Index zu sortieren und zu erstellen). Jetzt ist der ganze schöne Raum verschwunden. Wir fangen an, die Blöcke wieder aufzuteilen - und kommen gleich wieder an den Ausgangspunkt zurück.

Du hast keinen Platz gespart.

Der Index ist genau so, wie er war.

Sie würden nur Ihre Zeit verschwenden, um es wieder aufzubauen, was dazu führen würde, dass sich dieser Teufelskreis wiederholt.

Die Logik hier ist solide, aber sie ist gegen ein leselastiges Lastprofil vorgespannt.

Ein "fetter" Index (dh ein Index mit vielen Lücken) bietet in der Tat ausreichend Platz für neue und verschobene Zeilen, wodurch Seitenteile reduziert und das Schreiben beschleunigt werden. Wenn Sie jedoch aus diesem Fettindex lesen, müssen Sie mehr Seiten lesen, um die gleichen Daten zu erhalten, da Sie jetzt mehr leeren Raum durchsuchen. Dies verlangsamt das Lesen.

In Datenbanken mit hohem Lesezugriff möchten Sie Ihre Indizes regelmäßig neu erstellen oder organisieren. (Wie oft und unter welchen Bedingungen? Matt M hat bereits eine konkrete Antwort auf diese Frage.) In Datenbanken mit ungefähr gleichwertigen Lese- und Schreibaktivitäten oder in Datenbanken mit hohem Schreibaufwand können Sie die Leistung Ihrer Datenbank wahrscheinlich beeinträchtigen, indem Sie Indizes neu erstellen regelmäßig.


11

Die meisten Leute bauen sie regelmäßig um, damit sie nie fragmentiert werden. Wann Sie sie neu erstellen müssen, hängt davon ab, wie schnell sie fragmentiert werden. Einige Indizes müssen häufig neu erstellt werden, andere im Grunde nie. Schauen Sie sich das Skript an, das SQLFool zusammengestellt hat und das viele Aufgaben für Sie erledigt.


Nur eine kurze Info für die lieben Leser, dass das Skript von SQLFool seit> 5 Jahren nicht mehr aktualisiert wurde, sodass es möglicherweise nicht die neuesten Schnickschnack enthält, wenn es seine Sache macht.
LowlyDBA

Tatsächlich glaube ich, dass Michelle das letzte Mal, als ich die Site überprüfte (kann sie jetzt nicht erreichen (kann kein gutes Zeichen sein)), nicht mehr aktiv in SQL Server arbeitete und nicht die Absicht hatte, das Skript weiter zu bearbeiten . Wenn es für dich funktioniert, großartig! Berücksichtigen Sie bei Neuinstallationen die Skripte von Ola Hallengren : Ich habe beide verwendet, und es ist kein schwieriger Übergang.
RDFozz

7

Wie in der akzeptierten Antwort von Matt M erwähnt, lautet eine allgemeine Faustregel, dass Indizes, die zu mehr als 30% fragmentiert sind, neu erstellt werden sollten.

Mithilfe dieser Abfrage können Sie herausfinden, wie viele Indizes zu mehr als 30% fragmentiert sind (bei einigen sollten Sie sie neu erstellen):

SELECT DB_NAME() AS DBName,
       OBJECT_NAME(ind.object_id) AS TableName,
       ind.name AS IndexName,
       indexstats.index_type_desc AS IndexType,
       indexstats.avg_fragmentation_in_percent,
       indexstats.fragment_count,
       indexstats.avg_fragment_size_in_pages,
       SUM(p.rows) AS Rows 
  FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
         INNER JOIN sys.indexes AS ind ON (    ind.object_id = indexstats.object_id
                                           AND ind.index_id = indexstats.index_id)
         INNER JOIN sys.partitions AS p ON (    ind.object_id = p.object_id
                                            AND ind.index_id = p.index_id)
 WHERE indexstats.avg_fragmentation_in_percent > 30
 GROUP BY
       OBJECT_NAME(ind.object_id),
       ind.name,
       indexstats.index_type_desc,
       indexstats.avg_fragmentation_in_percent,
       indexstats.fragment_count,
       indexstats.avg_fragment_size_in_pages 
 ORDER BY indexstats.avg_fragmentation_in_percent DESC

1
Dies liefert keine Antwort. Die Frage ist nicht, wie ich Indizes mit "x" -Komprimierung finde, sondern wann ich Indizes neu erstellen soll.
Max Vernon

1
Dies gibt keine Antwort auf die Frage. Sobald Sie über eine ausreichende Reputation verfügen, können Sie jeden Beitrag kommentieren . Geben Sie stattdessen Antworten an, die nicht vom Fragesteller geklärt werden müssen . - Aus der Bewertung
LowlyDBA

2
@LowlyDBA - Es war vielleicht etwas prägnant, aber ich denke, es beantwortet die Frage und bietet etwas Nützliches für die Diskussion. Ich habe es ein bisschen erweitert, um zu erklären, wie. Amanda - Wenn meine Bearbeitung übermäßig fehlerhaft ist, können Sie sie jederzeit zurücksetzen.
RDFozz

Vielen Dank, dass Sie RDFozz. Sieht gut aus. Ja, mehr als 30% sind fragmentiert.
amandamaddox3

5

Wann sollte ich Indizes neu erstellen?

Wenn der Prozentsatz der Indexfragmentierung mehr als 30% beträgt.

Gibt es Gründe für die regelmäßige Neuerstellung von Indizes?

Es gibt keinen solchen Fall, aber im Allgemeinen ist die einmal wöchentliche Indexpflege über das Wochenende die beste Methode, um die Umgebung stabil zu halten.

Ich würde die Verwendung von Wartungsskripten von Ola Hallengren (beste Wartungsskripten) empfehlen, die Skripten an Ihre Umgebung anpassen und für die Ausführung über das Wochenende planen.

https://ola.hallengren.com/

Hinweis: Vergessen Sie nicht, die Statistiken nach dem Neuerstellen der Indizes zu aktualisieren, da beim Neuerstellen der Indizes nicht alle Statistiken aktualisiert werden.


Ich bin mir ziemlich sicher, dass Ihre Notiz falsch ist. Bei einer Indexwiederherstellung werden die Statistiken aktualisiert. Eine Indexreorganisation funktioniert nicht. Obwohl nur die Statistiken für die Objekte aktualisiert werden, die sich auf den Index beziehen, werden nicht alle Statistiken aktualisiert. Trotzdem empfehle ich, die Statistiken regelmäßig zu aktualisieren, um die Wahrscheinlichkeit einer Verlangsamung aufgrund von Parameter-Sniffing und schlechten Abfrageplänen aufgrund veralteter Statistiken zu verringern.
bmg002

1

Wie bei den meisten Dingen in der IT kommt es darauf an. Welches Problem versuchen Sie zu beheben, indem Sie Indizes neu erstellen? Können Sie zeigen, dass es das Problem tatsächlich behebt? Wenn ja, passen Sie die Zahlen an, bis Sie den geringsten Wartungsaufwand haben, den Sie zur Behebung des Problems benötigen.

Wenn sich das Problem dadurch nicht beheben lässt oder Sie es nur tun, um eine von Ihnen überwachte Kennzahl zu beruhigen, da dies möglicherweise zu einer Verbesserung der Situation führt, brennen Sie lediglich CPU und E / A und verschlimmern möglicherweise Ihr Problem.

Es gibt ein Argument, dass das Reparieren der Fragmentierung für Ihren Server keinen Unterschied macht. Lohnt es sich also überhaupt, dies regelmäßig zu tun?

https://www.brentozar.com/archive/2017/12/index-maintenance-madness/

http://brentozar.com/go/defrag

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.