Nachdem wir uns in den Teilen 1 – 3 um die Theorie gekümmert haben und geklärt haben was ein Index ist, soll es jetzt darum gehen wie Indizes überhaupt in der Realität gesetzt werden. Hier hat vermutlich jeder Datenbankdesigner sein eigenes Vorgehen. So ein paar allgemeingültige Regeln bzw. Vorgehensweisen gibt es aber trotzdem die zumindest bedacht werden sollten.

Indexdesign

Nach dem eine Tabelle entworfen wurde ist der erste Schritt zu überlegen welche Grundform die Tabelle haben soll. Wir müssen überlegen ob wir mit einem Clustered Index oder einen Heap arbeiten wollen. In den meisten Fällen wird die Entscheidung wohl auf einen Clustered Index hinauslaufen. Hierbei stellt sich gleich die nächste Frage. Haben wir in unserer Tabelle Spalten die sich als Schlüssel anbieten oder müssen wir ein künstlichen Schlüssel definieren? Im Idealfall haben wir einen eindeutigen Schlüssel bereits in der Tabelle. Dann können wir diesen für den Clustered Index nutzen. Allerdings müssen wir hier immer beachten wie wir den Clustered Index verwenden wollen. Haben wir eine Tabelle mit der häufig gejoint wird, die häufig in anderen Tabellen referenziert wird, sollten wir nach Möglichkeit numerische Werte nahmen. Also je nach Größe der Datei einen INT oder einen BIGINT Wert. Dies ist auch immer anhängig von der Größe der Tabelle und wie häufig sie gejoint wird. Wenn wir künstliche Schlüssel wählen bietet sich hierbei ein Autoincrement Wert an. Dabei wird automatisch in einer Spalte bei jedem Eintrag hochgezählt. Angegeben wird der Autoincrement Wert mit einem Startwert und einem Inkrementschritt. Häufig sieht man hier jeweils die Werte 1 stehen. Als Inkrementschritt ist die 1 sicher ein sinnvoller Wert, allerdings verschenken wir durch die 1 als Startwert die Hälfte unseres Wertebereichs, da sowohl der INT als auch der BIGINT auch in den negativen Bereich gehen. Unter Umständen können wir so bei einer Tabelle die wir eigentlich für einen BIGINT vorgesehen hatten doch einen INT nutzen und sparen somit 50% des Speicherplatzes für den künstlichen Schlüssel.

Für einen Nonclustered Index werden immer schon vorhandene Spalten aus der Tabelle genutzt. Hier einen künstlichen Schlüsselwert zu nutzen ergibt – aus meiner Sicht – keinen Sinn. Falls doch jemand einen sinnvollen Einsatzzweck kennt, den gerne in die Kommentare posten. Jetzt stellt sich die Frage wann wir einen zusätzlichen Index setzten und wann nicht. Grundsätzlich gilt wie bereits in Teil 1 erwähnt, dass ein Index eine Abfrage schnell machen kann aber das Einfügen von Daten in die Tabelle verlangsamt. Hier muss immer abgewogen werden, dass nicht zu viele Indizes gesetzt werden. Die wichtigsten Abfragen sollten mit Indizes optimiert werden. Bei manch selten ausgeführten Abfragen kann man vielleicht drauf verzichten. Oftmals kann man sich Indizes sparen in dem man in bereits vorhandenen zusätzliche Spalten entweder in den Schlüssel mit aufnimmt oder als Include-Spalten hinzufügt. Dabei muss allerdings beachtet werden, dass die Reihenfolge der Spalten im Index entscheidend dafür ist ob er genutzt werden kann oder nicht. Die zweite Spalte in einem Index kann nur verwendet werden wenn in der Abfrage auch die erste Spalte verwendet wird. Wenn man dies nicht beachtet entstehen häufig zu wenig genutzte Indizes. Oftmals kann auch schon ein tauschen der Spalten dazu führen, dass ein bisher nicht genutzter Index auf einmal einen Performanceboost für einen Abfrage bringt. Achtung hierbei, dass nicht andere Abfragen wieder langsamer werden.

Indizierung ist ein Kapitel an das man sich langsam rantasten muss. Je genauer man seine Datenbank und das Nutzerverhalten kennt, desto besser kann man optimieren und Indizes nutzten. Dafür ist es wichtig Daten über das Nutzerverhalten zu sammeln. Wie oft wird welcher Index verwendet. Weiteren Aufschluss geben auch die „Missing Index“ Daten des SQL Servers. Allerdings darf hier auf keinen Fall blind alle Vorschlägen des SQL Servers nachgegangen werden, da hier oft Indizes für einzelne Abfragen zu finden sind die im Gesamten das System eher verlangsamen. Das gilt für alle automatischen Tools zur Indexoptimierung im SQL Server. Man kann deren Daten als Hinweis nehmen sollte aber jeden einzelnen Vorschlag genau überprüfen und kritisch betrachten ob wirklich die Vorteile überwiegen. Ein System mit zu vielen Indizes bringt keine Performancevorteile sondern eher Nachteile.

Als Fazit zum Thema Indizes lässt sich sagen, dass sie ein ganz entscheidendes Element für das performante Arbeiten in einer Datenbank sind aber das korrekte Setzen von Indizes keine einfache Aufgabe ist. Indizierung ist ein Thema, dass auch während des Betriebs der Datenbank immer weiter verfolgt werden muss. Je länger eine Datenbank in Nutzung ist, desto eher finden sich Schwachstellen die man durch Indizierung abmildern kann.