SQL-Skript: Fehlende Datenbankindizes finden und optimieren

Eine langsame Datenbank ist oft kein Problem der Hardware, sondern der fehlenden oder falsch gesetzten Indizes. Microsoft SQL Server protokolliert im laufenden Betrieb selbst, an welchen Stellen ein Index die Abfragen beschleunigen würde. Dieses Wissen liegt in sogenannten dynamischen Verwaltungssichten (Dynamic Management Views, kurz DMVs) bereit – man muss es nur auslesen. Genau das leistet dieses SQL-Skript: Es wertet diese Statistiken aus und erzeugt daraus fertige CREATE INDEX-Befehle als Vorschlag.

Das Skript lässt sich vollkommen unabhängig von cobra einsetzen. Es ist ein eigenständiges Werkzeug für jeden, der eine Microsoft-SQL-Server-Datenbank betreibt und deren Performance verbessern möchte – ob Administrator, Entwickler oder technisch versierter Anwender. Voraussetzung ist lediglich ein Zugriff auf die Datenbank mit ausreichenden Leserechten auf die Systemsichten sowie ein Werkzeug wie das SQL Server Management Studio (SSMS) oder Azure Data Studio.

Was macht das Skript?

Das Skript greift auf drei zusammengehörige Systemsichten von SQL Server zu und verknüpft sie miteinander. In diesen Sichten sammelt der Server fortlaufend Hinweise darauf, welche Indizes fehlen und wie nützlich sie wären. Aus diesen Rohdaten berechnet das Skript einen Nutzwert und setzt zugleich einen einsatzbereiten Befehl zum Anlegen des Index zusammen. Das Ergebnis ist eine übersichtliche Tabelle, in der die lohnenswertesten Indizes ganz oben stehen.

Wichtig zu wissen: Das Skript legt selbst keine Indizes an. Es liefert ausschließlich Vorschläge in Textform. Ob und welche dieser Vorschläge tatsächlich umgesetzt werden, entscheidet der Anwender bewusst und eigenständig. So behält man die volle Kontrolle.

Welche Spalten zeigt die Ergebnistabelle – und was bedeuten sie?

Damit die Ausgabe ohne Vorwissen verständlich ist, wurden alle Spalten ins Deutsche übersetzt und um zusätzliche, hilfreiche Informationen ergänzt. Die folgende Übersicht erklärt jede Spalte:

Spalte	Bedeutung
Nutzwert	Eine berechnete Kennzahl, die schätzt, wie lohnenswert der vorgeschlagene Index ist. Sie ergibt sich aus den durchschnittlichen Abfragekosten, multipliziert mit der geschätzten prozentualen Verbesserung und der Anzahl der Zugriffe. Je höher der Wert, desto größer der erwartete Gewinn. Es handelt sich um eine reine Vergleichszahl ohne Einheit – sie dient dazu, die Vorschläge untereinander zu priorisieren.
Datenbank	Der Name der Datenbank, auf die sich der Vorschlag bezieht. Hilfreich, wenn auf der Server-Instanz mehrere Datenbanken liegen.
Tabelle	Die betroffene Tabelle inklusive Schema, zum Beispiel [dbo].[Kunden]. Hier würde der Index angelegt werden.
Verbesserung_%	Die von SQL Server geschätzte durchschnittliche Verbesserung in Prozent, die der Index für die betroffenen Abfragen bringen würde. Ein hoher Wert bedeutet, dass die jeweiligen Abfragen deutlich schneller würden.
Suchzugriffe	Wie oft der Index bei gezielten Suchen (sogenannten „Seeks“) verwendet worden wäre. Das sind Zugriffe, bei denen gezielt einzelne Datensätze gesucht werden – genau hier glänzen Indizes besonders.
Bereichszugriffe	Wie oft der Index bei vollständigen Durchläufen (sogenannten „Scans“) genutzt worden wäre. Diese Zugriffe durchsuchen größere Datenmengen.
Durchschnittskosten	Die durchschnittlichen Kosten der betroffenen Abfragen – ein SQL-Server-interner Schätzwert für den Aufwand. Je höher, desto „teurer“ ist die Abfrage in ihrer jetzigen Form.
Letzter_Bedarf	Der Zeitpunkt, zu dem zuletzt eine Abfrage lief, die diesen Index gebraucht hätte. So lässt sich einschätzen, ob der Bedarf aktuell ist oder schon länger zurückliegt.
Indexbefehl	Der fertige CREATE INDEX-Befehl als Text. Er kann kopiert und – nach Prüfung – ausgeführt werden. Der automatisch erzeugte Indexname sollte vorher in einen sprechenden Namen umbenannt werden, etwa IX_Kunden_Nachname_PLZ.

Das Skript individuell anpassen

Das Skript wurde bewusst so aufgebaut, dass der Anwender es eigenständig anpassen kann, ohne in die eigentliche Abfrage eingreifen zu müssen. Im Abschnitt „Einstellungen“ am Anfang stehen mehrere Parameter bereit:

• Mindest-Nutzwert: Legt fest, ab welchem berechneten Wert ein Vorschlag überhaupt angezeigt wird. Ein hoher Wert blendet kleinere Vorschläge aus und zeigt nur die wirklich lohnenswerten Indizes. Wer zunächst alle Vorschläge sehen möchte, setzt diesen Wert auf 0.
• Datenbank: Optional lässt sich die Auswertung auf eine bestimmte Datenbank beschränken. Bleibt der Wert leer, wird die aktuell gewählte Datenbank ausgewertet.
• Mindestanzahl an Zugriffen: Damit lassen sich sehr selten genutzte Vorschläge ausblenden, sodass nur Indizes mit echtem, regelmäßigem Bedarf erscheinen.

Wichtig: Wann liefert das Skript Ergebnisse?

Manchmal zeigt das Skript zunächst keine Vorschläge an. Das ist kein Fehler, sondern hat nachvollziehbare Gründe, die man kennen sollte:

• Die zugrunde liegenden Statistiken werden bei jedem Neustart des SQL Servers vollständig zurückgesetzt. Direkt nach einem Neustart liegen also noch keine Daten vor.
• SQL Server sammelt diese Hinweise nur, wenn tatsächlich Abfragen laufen, die von einem Index profitiert hätten. Auf einer wenig genutzten Test- oder Entwicklungsdatenbank entsteht dieser Bedarf selten. Aussagekräftig werden die Daten erst nach einigen Tagen bis Wochen produktivem Betrieb.
• Ist der Mindest-Nutzwert zu hoch eingestellt, werden vorhandene, aber kleinere Vorschläge herausgefiltert. In diesem Fall hilft es, den Wert testweise auf 0 zu setzen.

Vorsicht: Wenn es zu viele Indizes gibt

Indizes sind ein wirkungsvolles Mittel, um Abfragen zu beschleunigen – aber sie sind kein kostenloses Geschenk. Es ist ein verbreiteter Irrtum, dass „mehr Indizes“ automatisch „mehr Geschwindigkeit“ bedeuten. Tatsächlich kann ein Übermaß an Indizes die Datenbank spürbar ausbremsen. Diese Nachteile sollte man kennen, bevor man Vorschläge umsetzt:

• Langsamere Schreibvorgänge: Jeder Index muss bei jedem INSERT, UPDATE und DELETE mit aktualisiert werden. Je mehr Indizes auf einer Tabelle liegen, desto mehr Arbeit fällt bei jeder Änderung an – Schreiboperationen werden dadurch langsamer.
• Höherer Speicherbedarf: Indizes belegen zusätzlichen Speicherplatz auf der Festplatte und im Arbeitsspeicher. Bei großen Tabellen kann das erheblich ins Gewicht fallen.
• Längere Wartung und Backups: Indizes müssen gepflegt werden (etwa durch Reorganisation oder Neuaufbau bei Fragmentierung) und vergrößern das Datenvolumen, das gesichert und wiederhergestellt werden muss.
• Redundante und überlappende Indizes: Die Vorschläge berücksichtigen keine bereits vorhandenen Indizes. So entstehen leicht mehrere sehr ähnliche Indizes, die denselben Zweck erfüllen – das verursacht doppelten Pflegeaufwand ohne zusätzlichen Nutzen.
• Nicht jede Empfehlung ist optimal: Die von SQL Server vorgeschlagene Reihenfolge der Spalten ist nicht immer ideal. Eine fachliche Bewertung durch eine erfahrene Person ist daher empfehlenswert.

Die goldene Regel lautet deshalb: lieber wenige, gut durchdachte Indizes als viele ungezielte. Die Vorschläge des Skripts sind als Kandidaten zu verstehen, die man vor dem Anlegen prüft – nicht als Liste, die man blind abarbeitet. Idealerweise prüft man zusätzlich, ob bereits ein passender Index existiert, und beobachtet nach dem Anlegen, ob die gewünschte Verbesserung tatsächlich eintritt.

Fazit

Dieses SQL-Skript ist ein einfaches, aber wirkungsvolles Werkzeug, um fehlende Indizes in einer Microsoft-SQL-Server-Datenbank sichtbar zu machen und gezielt zu optimieren. Durch die anpassbaren Parameter und die verständlich benannten Spalten kann es jeder Anwender eigenständig an seine Umgebung anpassen – ganz unabhängig von cobra. Wer dabei die Schreiblast und den Pflegeaufwand zusätzlicher Indizes im Blick behält, kann die Datenbank-Performance mit überschaubarem Aufwand spürbar verbessern.