Wenn der Index ohne Wartung wächst
Warum eine stabile Seitendichte keine Ruhe im Index bedeutet – und wie sich die Kosten des Eingreifens und Abwartens vergleichen lassen.
Der Befund in 30 Sekunden
- Ohne Wartung stabilisierte sich die mittlere Seitendichte in unserem Versuch um 68 %, bei beiden getesteten Startzuständen.
- Das ist kein Ruhezustand: Im Plateau entstanden weiter rund 225 Split-Logrecords je 10.000 Inserts.
- Abwarten kostet Platz: Nach 60 simulierten Tagen belegte der ungewartete Index 24 % mehr Blattseiten als einer mit frühem REBUILD. Eingreifen kostet ebenfalls; welche Rechnung aufgeht, entscheidet die Last.
- Bei aufsteigenden Schlüsseln hilft die beim REBUILD angelegte Reserve frisch angehängten Zeilen nicht, wenn diese später wachsen.
Abwarten ist auch eine Strategie
Eine mögliche Wartungsstrategie ist, zunächst gar nicht einzugreifen. Was passiert dann bei fortgesetzten zufällig verteilten Inserts? In unseren Versuchen stabilisiert sich die mittlere Seitendichte, während weitere Split-Logrecords entstehen. Daraus ergibt sich die praktische Frage: Ist dieser Zustand für die eigene Arbeitslast akzeptabel, oder lohnt ein gezielter Eingriff?
Das ist Teil 3 einer Reihe. Teil 1 erklärt Seiten, Splits und Reserve mit Bildern. Teil 2 vergleicht REORGANIZE und REBUILD bei gleicher Ausgangslage.
Der Aufbau
Eine GUID als Clustering-Key plus 100 Byte Nutzdaten, 123 Byte je Zeile. Die Schlüssel stammen aus einer reproduzierbaren, breit verteilten Hashfolge.
- Zwei dichte Starts: 100.000 Zeilen, einmal mit Fillfactor 100 aufgebaut, einmal mit Fillfactor 81. Danach dieselben zufällig verteilten Inserts, einzeln, ohne jede Index- oder Statistikwartung. Gemessen nach jedem Schritt: Seitendichte über alle Blattseiten, Fragmentierung, Split-Logrecords (
LOP_DELETE_SPLIT, wie in Teil 2 erklärt). - Plateaukriterium, vorab festgelegt: Über die letzte Million eingefügter Zeilen schwankt die Dichte um höchstens einen Prozentpunkt und steigt oder fällt um höchstens 0,5 Prozentpunkte je Million. Wir lassen mindestens bis 3,1 Millionen Zeilen wachsen und dann so lange, bis das mit mindestens elf Messpunkten erfüllt ist.
- Gegenkontrolle: die ungewarteten Läufe aus Teil 2, leer gestartet, auf SQL Server 2022 und 2025.
Die dichten Starts liefen nur auf SQL Server 2022, die Gegenkontrolle auf beiden Versionen.
Das Plateau
Die Seitendichte kommt zur Ruhe, die Split-Logrecords laufen weiter
Zwei dichte Starts mit 100.000 Zeilen, danach nur zufällig verteilte Einzelinserts. SQL Server 2022.
Daten zur Grafik
| Zeilen (Mio.) | FF100 Dichte | FF100 Split-Logrecords je 10.000 | FF81 Dichte | FF81 Split-Logrecords je 10.000 |
|---|---|---|---|---|
| 0,10 | 98,78 % | – | 81,82 % | – |
| 0,11 | 53,96 % | 1.593 | 89,20 % | 22 |
| 0,12 | 58,70 % | 9 | 71,28 % | 696 |
| 0,13 | 63,59 % | 0 | 58,27 % | 846 |
| 0,14 | 68,48 % | 0 | 58,06 % | 282 |
| 0,15 | 73,12 % | 11 | 61,23 % | 60 |
| 0,16 | 77,05 % | 39 | 65,09 % | 13 |
| 0,17 | 78,30 % | 146 | 68,94 % | 12,0 |
| 0,18 | 76,22 % | 299 | 72,57 % | 22 |
| 0,19 | 72,04 % | 427 | 75,37 % | 63 |
| 0,20 | 67,30 % | 515 | 76,77 % | 130 |
| 0,21 | 64,36 % | 449 | 76,37 % | 229 |
| 0,22 | 62,66 % | 385 | 74,58 % | 309 |
| 0,23 | 62,00 % | 309 | 71,34 % | 424 |
| 0,24 | 62,36 % | 214 | 68,16 % | 459,0 |
| 0,25 | 63,40 % | 146 | 65,68 % | 440 |
| 0,26 | 64,69 % | 119,0 | 64,12 % | 384,0 |
| 0,27 | 66,37 % | 77 | 63,20 % | 339 |
| 0,28 | 68,10 % | 68 | 63,07 % | 260 |
| 0,29 | 69,82 % | 68 | 63,32 % | 216 |
| 0,30 | 71,18 % | 96,0 | 63,92 % | 175,0 |
| 0,40 | 67,83 % | 260,4 | 72,45 % | 129 |
| 0,50 | 65,63 % | 266,5 | 67,23 % | 296,5 |
| 0,60 | 69,86 % | 150,8 | 65,75 % | 261,8 |
| 0,70 | 70,20 % | 215,0 | 68,93 % | 159,8 |
| 0,80 | 67,84 % | 281,6 | 70,12 % | 195,2 |
| 0,90 | 66,56 % | 267,3 | 69,09 % | 250,2 |
| 1,00 | 66,81 % | 224,7 | 67,50 % | 276,4 |
| 1,10 | 68,13 % | 182,7 | 66,86 % | 253,5 |
| 1,20 | 69,06 % | 191,9 | 67,05 % | 224,9 |
| 1,30 | 69,53 % | 204,3 | 67,70 % | 201,8 |
| 1,40 | 69,31 % | 234 | 68,69 % | 184,4 |
| 1,50 | 68,72 % | 251,6 | 69,23 % | 198,8 |
| 1,60 | 68,12 % | 256,9 | 69,26 % | 222,6 |
| 1,70 | 67,63 % | 254,7 | 68,95 % | 241,2 |
| 1,80 | 67,33 % | 247,6 | 68,56 % | 247,1 |
| 1,90 | 67,34 % | 230 | 68,21 % | 248 |
| 2,00 | 67,61 % | 211,4 | 67,90 % | 247,4 |
| 2,10 | 67,83 % | 214,6 | 67,68 % | 243,7 |
| 2,20 | 68,09 % | 210,5 | 67,54 % | 239,6 |
| 2,30 | 68,38 % | 204,7 | 67,56 % | 227,6 |
| 2,40 | 68,74 % | 198,1 | 67,73 % | 214,8 |
| 2,50 | 68,97 % | 208,9 | 67,90 % | 215,8 |
| 2,60 | 68,99 % | 222,8 | 68,09 % | 213,3 |
| 2,70 | 68,97 % | 225,6 | 68,32 % | 206,9 |
| 2,80 | 68,91 % | 230,3 | 68,51 % | 208,7 |
| 2,90 | 68,79 % | 236,5 | 68,65 % | 213,6 |
| 3,00 | 68,53 % | 250,9 | 68,70 % | 221,9 |
| 3,10 | 68,37 % | 242 | 68,76 % | 220,4 |
| 3,20 | 68,20 % | 244,3 | 68,70 % | 230,5 |
| 3,30 | – | – | 68,69 % | 226,1 |
| 3,40 | – | – | 68,65 % | 230,8 |
| 3,50 | – | – | 68,65 % | 226,2 |
| 3,60 | – | – | 68,48 % | 245,8 |
Erste 20 Schritte zu je 10.000 Inserts, danach Schritte zu 100.000. Split-Logrecords je 10.000 = Split-Logrecords des Schritts, umgerechnet auf 10.000 neue Zeilen. Plateaufenster: die letzte Million Zeilen je Start (11 Messpunkte).
| Start | Dichte am Anfang | Zeilen am Ende | Dichte am Ende | Dichte in der letzten Million |
|---|---|---|---|---|
| FF100 | 98,8 % | 3,2 Mio. | 68,20 % | 68,09–68,99 % |
| FF81 | 81,8 % | 3,6 Mio. | 68,48 % | 68,09–68,76 % |
Im ersten Schritt ist die Splitaktivität beim dicht gebauten Index besonders hoch; die Dichte fällt in den ersten 10.000 Inserts von 98,8 % auf 54,0 %. Danach schwingt sie sich ein. Ab etwa 1,4 Millionen Zeilen liegen beide Kurven höchstens gut einen Prozentpunkt auseinander, bei 3,2 beziehungsweise 3,6 Millionen Zeilen ist unser Plateaukriterium über die jeweils letzte Million erfüllt. Der Startzustand verliert sich.
Die leer gestarteten Läufe aus Teil 2 enden auf SQL Server 2022 und 2025 bei 68,24 %. Das ist eine gerundete Übereinstimmung zweier verschiedener Versuche, kein Genauigkeitsnachweis. Die 68 % sind eine Beobachtung in diesem Versuch: weder ein universeller Grenzwert noch ein Wartungsziel.
Die Splits hören nicht auf
Ein stabiler Durchschnitt klingt nach Ruhe. Das ist er nicht. Im Plateau entstehen bei Start FF100 226,4 und bei Start FF81 223,1 Split-Logrecords je 10.000 Inserts. Die leer gestarteten Läufe zeigen dasselbe: 4.559 Split-Logrecords in den letzten 200.000 Zeilen, also rund 228 je 10.000.
Dichte und Splitrate beantworten verschiedene Fragen. Die Dichte beschreibt den Zustand: Wie voll sind die Seiten im Mittel? Die Splitrate beschreibt die Veränderung: Wie viel wird umgebaut, damit es so bleibt? Ein stabiler Mittelwert sagt auch nicht, dass alle Seiten ähnlich voll sind. Frisch geteilte, halb volle Seiten und fast volle Seiten gleichen sich im Durchschnitt aus. Der Durchschnitt steht still, weil der Umbau gleichmäßig weiterläuft.
Abwarten gegen Eingreifen
Ohne Wartung fallen keine Wartungskosten an. Dafür zahlt der Index an zwei anderen Stellen: mit wiederkehrenden Splits bei einem Teil der Inserts und mit mehr Blattseiten.
Nach 60 Tagen ohne Wartung: mehr Blattseiten und mehr Split-Logrecords
600.000 Zeilen, 10.000 Inserts je Tag, SQL 2022 und 2025 identisch.
Daten zur Grafik
| Strategie | Blattseiten 2022 | Blattseiten 2025 | Dichte am Ende | Split-Logrecords 2022 | Split-Logrecords 2025 | REBUILD / REORGANIZE |
|---|---|---|---|---|---|---|
| Keine Wartung | 13.574 | 13.574 | 68,2 % | 13.631 | 13.631 | 0 / 0 |
| Früher REBUILD FF80 | 10.962 | 10.962 | 84,5 % | 4.199 | 4.199 | 20 / 0 |
Tag 60 nach 600.000 Einzelinserts, leerer Start, GUID plus 100 Byte. Der letzte REBUILD lief an Tag 57; die Dichte des REBUILD-Index ist der Stand 3 Tage danach.
| Strategie (60 Tage) | Blattseiten am Ende | Dichte am Ende | Split-Logrecords | Wartungsaufwand (SQL 2022) |
|---|---|---|---|---|
| Keine Wartung | 13.574 | 68,2 % | 13.631 | – |
| Früher REBUILD FF80 | 10.962 | 84,5 % | 4.199 | 20 REBUILDs, 4,4 s, 4,3 MiB Log |
Der ungewartete Index belegt am Ende des Versuchs 24 % mehr Blattseiten und hat gut dreimal so viele Split-Logrecords erzeugt. Ein Scan über denselben Bestand muss bei geringerer Dichte mehr Blattseiten anfassen; Seiten, die schon im Buffer Pool liegen, verursachen dabei keine erneute Leseoperation von der Platte. Für Punktzugriffe spielt die Seitenzahl kaum eine Rolle. Aus 24 % mehr Seiten folgen deshalb nicht 24 % langsamere Abfragen; Lesezeiten haben wir hier nicht gemessen.
Die Gegenrechnung gehört dazu: Die REBUILD-Strategie brauchte 20 Eingriffe. Unsere Wartungszahlen gelten für diesen synthetischen Einzelindex, offline unter SIMPLE, gemessen als erzeugte Logrecord-Bytes. Ein Online-REBUILD schreibt deutlich mehr Log (Teil 2: 34 statt 1,6 MiB im eingefrorenen Vergleich), und ein Offline-REBUILD kann den Zugriff auf die Tabelle für die Dauer blockieren. Bei einem großen Produktionsindex verschieben sich diese Kosten erheblich. Keine routinemäßige Wartung kann deshalb die bessere Gesamtentscheidung sein.
Wann sich Eingreifen lohnen kann
Für einen Index mit zufällig verteilten Inserts lässt sich die Frage „abwarten oder eingreifen?“ an vier Punkten festmachen:
- Wie schreiblastig ist er? Je mehr Inserts in bestehende Bereiche, desto mehr zählen die wiederkehrenden Splits.
- Wie wird er gelesen? Viele Scans über große Bereiche profitieren von höherer Dichte; Punktzugriffe kaum.
- Was kostet der Eingriff? Größe des Index, Recovery-Modell, Online- oder Offline-Betrieb, Wartungsfenster.
- Was zeigt die Messung? Dieselbe Last vor und nach einem Probeeingriff, einschließlich der Zeit bis zum nächsten.
Vertiefung: Ein Jahr mit Reserve
Wie oft muss ein früher REBUILD laufen? Wir haben die Reservestrategie über 365 simulierte Tage verlängert, jeden Tag 10.000 Inserts, REBUILD sobald die Fragmentierung 1 % überschreitet. Ein simulierter Tag ist eine feste Insertmenge, kein Kalendertag.
Die Abstände zwischen zwei REBUILDs werden mit wachsendem Index länger
Früher REBUILD mit Fillfactor 70 und 80, 365 simulierte Tage, SQL 2022. SQL 2025 identisch.
Daten zur Grafik
| REBUILD Nr. | FF70 Tag | FF70 Abstand | FF80 Tag | FF80 Abstand |
|---|---|---|---|---|
| 1 | 5 | erster | 5 | erster |
| 2 | 6 | 1 | 6 | 1 |
| 3 | 8 | 2 | 7 | 1 |
| 4 | 10 | 2 | 8 | 1 |
| 5 | 12 | 2 | 9 | 1 |
| 6 | 15 | 3 | 10 | 1 |
| 7 | 18 | 3 | 12 | 2 |
| 8 | 22 | 4 | 14 | 2 |
| 9 | 27 | 5 | 16 | 2 |
| 10 | 33 | 6 | 18 | 2 |
| 11 | 40 | 7 | 20 | 2 |
| 12 | 48 | 8 | 23 | 3 |
| 13 | 58 | 10 | 26 | 3 |
| 14 | 70 | 12 | 29 | 3 |
| 15 | 84 | 14 | 33 | 4 |
| 16 | 101 | 17 | 37 | 4 |
| 17 | 121 | 20 | 41 | 4 |
| 18 | 146 | 25 | 46 | 5 |
| 19 | 174 | 28 | 51 | 5 |
| 20 | 208 | 34 | 57 | 6 |
| 21 | 249 | 41 | 63 | 6 |
| 22 | 298 | 49 | 70 | 7 |
| 23 | 356 | 58 | 77 | 7 |
| 24 | – | – | 85 | 8 |
| 25 | – | – | 94 | 9 |
| 26 | – | – | 104 | 10 |
| 27 | – | – | 115 | 11 |
| 28 | – | – | 127 | 12 |
| 29 | – | – | 140 | 13 |
| 30 | – | – | 155 | 15 |
| 31 | – | – | 171 | 16 |
| 32 | – | – | 189 | 18 |
| 33 | – | – | 208 | 19 |
| 34 | – | – | 230 | 22 |
| 35 | – | – | 254 | 24 |
| 36 | – | – | 280 | 26 |
| 37 | – | – | 309 | 29 |
| 38 | – | – | 341 | 32 |
| Jahresende | 365 | offen: 9 | 365 | offen: 24 |
Der erste REBUILD lief in beiden Läufen an Tag 5, sobald der Index 1.000 Blattseiten überschritt und die Fragmentierung über 1 % lag. Abstand = Tage seit dem vorigen REBUILD. SQL Server 2025: dieselben REBUILD-Tage.
| Fillfactor | REBUILDs im Jahr | Längstes abgeschlossenes Intervall | Split-Logrecords | Wartung gesamt (SQL 2022) | Blattseiten am Ende |
|---|---|---|---|---|---|
| 70 | 23 | 58 Tage | 5.327 | 19,5 s · 19,8 MiB | 77.392 |
| 80 | 38 | 32 Tage | 8.805 | 29,8 s · 29,4 MiB | 65.592 |
Die Intervalle werden mit der Zeit länger. Jeden Tag kommen gleich viele Zeilen dazu, aber der Index wird größer. Dieselben 10.000 Zeilen verteilen sich auf immer mehr Seiten, und die Reserve jeder einzelnen Seite reicht länger. Ein Intervall vom Jahresende sagt deshalb nichts über einen jungen oder kleinen Index und ist keine Kalenderplanung.
Auch zwischen zwei REBUILDs entstehen Split-Logrecords, nur wenige: Im längsten FF70-Intervall, von Tag 298 bis Tag 356, kamen bei 580.000 neuen Zeilen 539 zusammen. Hochgerechnet mit der Plateau-Rate wären es ohne Wartung rund 13.000 gewesen; das ist eine Hochrechnung, kein eigener Kontrolllauf für dieses Intervall.
FF70 brauchte weniger Eingriffe als FF80 und erzeugte weniger Split-Logrecords, belegte am Jahresende aber 18 % mehr Seiten. Dieser Endzustand hängt auch davon ab, wie lange der letzte REBUILD jeweils zurücklag. Welcher Wert besser ist, hängt davon ab, was teurer ist: Schreiben oder Lesen.
Wachsende Zeilen bei aufsteigenden Schlüsseln
Bei IDENTITY oder NEWSEQUENTIALID landen neue Zeilen im einfachen Fall am Ende des Index. Neue Seiten werden dort angehängt und voll gefüllt. Der Fillfactor eines früheren REBUILD wirkt auf diese neuen Seiten nicht: Er galt nur für die Seiten, die beim REBUILD schon existierten.
Das wird sichtbar, wenn Zeilen nach dem Einfügen wachsen. Wir haben 90.000 Zeilen mit FF70 oder FF100 aufgebaut, 10.000 angehängt und danach 333 der neu angehängten Zeilen um je 100 Byte vergrößert.
Wachsende Updates auf neuen Seiten: gleiche Split-Logrecords bei FF70 und FF100
Je Schlüsseltyp und Fillfactor, Median aus drei Läufen, SQL 2022 und 2025 identisch.
LOP_DELETE_SPLIT), Werte 0 und 1 sind als Zahl beschriftet. Über Updates auf älteren, beim REBUILD vorhandenen Seiten sagt dieser Versuch nichts. Quelle: Eigene Messung, LAB-12, SQL Server 2022/2025, 05.10.2026Daten zur Grafik
| Schlüssel | Fillfactor | Seiten vorher | nach Anhängen | nach Updates | Dichte nach Anhängen | Split-Logrecords Anhängen | Split-Logrecords Updates |
|---|---|---|---|---|---|---|---|
| IDENTITY | 70 | 1.837 | 1.982 | 2.127 | 72,9 % | 1 | 145 |
| IDENTITY | 100 | 1.305 | 1.450 | 1.595 | 99,7 % | 0 | 145 |
| NEWSEQUENTIALID | 70 | 2.046 | 2.207 | 2.368 | 72,2 % | 0 | 162 |
| NEWSEQUENTIALID | 100 | 1.452 | 1.613 | 1.773 | 98,8 % | 0 | 162 |
Median aus drei Läufen; alle drei Läufe und beide Versionen liefern dieselben Zahlen. Die neuen Seiten am Indexende werden voll gefüllt, unabhängig vom Fillfactor des Altbestands.
| Schlüssel | Fillfactor | Split-Logrecords beim Anhängen | Split-Logrecords bei 333 Updates |
|---|---|---|---|
| IDENTITY | 70 | 1 | 145 |
| IDENTITY | 100 | 0 | 145 |
| NEWSEQUENTIALID | 70 | 0 | 162 |
| NEWSEQUENTIALID | 100 | 0 | 162 |
In diesem Versuch wachsen nur frisch angehängte Zeilen. Die beim REBUILD angelegte Reserve im älteren Bereich hilft ihnen nicht: FF70 und FF100 ergeben dieselben Zahlen. Wachsen dagegen Zeilen auf den bereits neu aufgebauten Seiten, kann der dortige freie Platz relevant sein; das haben wir hier nicht gemessen. Für die Entscheidung muss man deshalb prüfen, wo und um wie viel Zeilen wachsen. Hotspots am Indexende unter vielen gleichzeitigen Schreibern und das Verhalten von NEWSEQUENTIALID nach Neustarts haben wir nicht untersucht.
Vertiefung: Warum ungefähr zwei Drittel?
Ein Split hinterlässt zwei etwa halb volle Seiten. Danach füllen sie sich, bis sie wieder voll sind und erneut geteilt werden. Bei zufällig verteilten Inserts sind die Seiten deshalb über viele Füllstände verstreut, und der Mittelwert liegt deutlich unter „voll“. Andrew Yaos Analyse zufällig wachsender B-Bäume hoher Ordnung liefert dafür mit ln 2 ≈ 69 % eine theoretische Orientierung (Acta Informatica 9, 1978). SQL-Server-Seiten mit ganzen Zeilen, Verwaltungsfläche und konkretem Splitverhalten sind damit nicht gleichgesetzt. Dass unsere Beobachtung in derselben Gegend liegt, ist eine Orientierung, keine Herleitung.
Was das für die Wartung heißt
Der Zustand ohne Wartung ist kein Ziel und keine Schwelle. Er zeigt, wohin ein Index mit zufällig verteilten Inserts ohne Eingriff läuft: im Mittel etwa zwei Drittel voll, mit gleichmäßig weiterlaufenden Splits. Ob das ein Problem ist, entscheidet die Arbeitslast.
Die Leitlinie der Reihe:
Indexwartung braucht ein messbares Ziel. Entscheidend ist, ob ihre Wirkung auf die Arbeitslast die Kosten und die Beeinträchtigung des Betriebs rechtfertigt.
Für die Muster aus dieser Reihe, als Ausgangspunkt für die eigene Prüfung:
| Muster | Was ohne Wartung passiert | Prüfkandidat |
|---|---|---|
| Zufällig verteilte Inserts, schreiblastig | Plateau um zwei Drittel Dichte, Splits laufen weiter | REBUILD mit Reserve, Intervall und Fillfactor messen |
| Zufällig verteilte Inserts, leselastig mit vielen Scans | Mehr Blattseiten für jeden Scan | REBUILD mit höherem Fillfactor, seltener |
| Aufsteigende Schlüssel, Zeilen bleiben unverändert | Seiten werden voll angehängt | kaum routinemäßige physische Wartung |
| Aufsteigende Schlüssel, frisch eingefügte Zeilen wachsen | Splits auf den neuen Seiten am Ende | Datenmodell, Zeilenwachstum und dessen Zeitpunkt prüfen |
| Wachsende Updates auf älteren Zeilen | Splits im bestehenden Bereich | zusätzlich lokale Reserve und Fillfactor prüfen |
| Kaum Änderungen | nichts | keine routinemäßige physische Wartung; Statistiken nur bei begründetem Bedarf aktualisieren |
Keine Zeile dieser Tabelle ist eine Regel. Jede ist eine Hypothese, die an der eigenen Last vorher und nachher gemessen wird.
Herkunft und weiterführende Arbeiten
Die Versuchsideen und Gegenproben dieser Reihe greifen insbesondere Jeff Modens Arbeiten zur Indexwartung auf. In seinem Vortrag „Black Arts“ Index Maintenance #1 stellt er eine Jahressimulation ohne Wartung neben mehrere Wartungsstrategien und gibt für die ungewartete Kurve eine mittlere Seitendichte von 68,24 % an. Diese Vergleichskurve ohne Wartung bezeichnet er als „Brent Line“, nach Brent Ozar; gemeint ist eine Referenzkurve, keine SQL-Server-Funktion und keine Wartungsschwelle. Den Namen verwendet er mindestens seit 2020 auf SQLServerCentral. Den Test mit dicht aufgebautem Start hat er uns im Austausch auf LinkedIn vorgeschlagen. Folien und Skripte stellt er für Lernzwecke frei zur Verfügung. Wir danken ihm für die Anregungen. Unsere Messwerte stammen aus dem PSG-Lab; ihre Bedingungen und Grenzen sind jeweils angegeben.
Grenzen der Messung
- Synthetische Daten, ein Clustered Index ohne Nebenindizes, feste Zeilenbreite, keine Deletes, keine Kompression, keine Partitionen.
- Je Startzustand eine deterministische Trajektorie; kein Streuungsmaß über verschiedene Zufallsfolgen. Das Plateau ist eine begrenzte Beobachtung nach unserem Kriterium, kein Beweis eines dauerhaften Grenzwerts.
- Die dichten Starts liefen nur auf SQL Server 2022 (16.0.4295.3); die leer gestarteten Kontrollen und die Jahresläufe auf 2022 und 2025 (17.0.5005.3). Wartungszeiten und Logmengen in den Tabellen sind SQL-2022-Werte; auf 2025 weichen sie leicht ab, Seiten, Split-Logrecords und Intervalle sind identisch.
- Serielle Last, MAXDOP 1, keine gleichzeitigen Schreiber. Wartung offline unter SIMPLE; Sperrwirkung und Online-Kosten im Jahreslauf nicht gemessen.
- Lesekosten nur über die Seitenzahl abgeleitet; Scans und Lesezeiten haben wir nicht gemessen.
- Ein simulierter Tag ist eine Insertmenge, keine Kalenderprognose.
- Geprüft am 05. und 06.10.2026. Die Versuchsbedingungen sind dokumentiert; zu einem öffentlichen Reproduktionspaket informieren wir gesondert.
Was macht Ihr Index, wenn niemand ihn wartet?
Jede Antwort wird sofort aufgelöst, mit Verweis auf die Stelle im Beitrag. Am Ende gibt es eine Einordnung und einen Link zum Teilen. Ohne Cookies.
Weiterlesen
- PSG: Teil 1 · Platz für die nächste Zeile
- PSG: Teil 2 · Aufgeräumt, aber ohne Platz
- Jeff Moden: „Black Arts“ Index Maintenance #1
- Brent Ozar: Stop Using Page Splits to Justify Lowering Fill Factor
- Andrew C. Yao: On random 2–3 trees, Acta Informatica, 1978
- Microsoft: Specify fill factor for an index