Heap und Clustered Index sind ein erster Schritt im Tabellendesign. Allerdings reihen sie noch nicht aus um effizient auf Daten zugreifen zu können und das ist ja da eigentliche Ziel von Indizes. Die Abfragen sollen schnell werden. Mit dem Clustered Index können wir schon bestimmte Abfragen beschleunigen. In den meisten Fällen reicht das aber noch nicht.

Nonclustered Index

Um zurück zu dem Beispiel aus Teil 2 zu kommen mit den Adressen. Hier haben wir die Sortierung nach Name, wollen wir aber wissen welcher Name zu einer bestimmten Telefonnummer gehört müssen wir noch die komplette Tabelle durchsuchen. Hier wäre ein Index auf der Telefonnummer sinnvoll. Wenn wir jetzt den Clustered Index auf die Telefonnummer legen statt auf den Namen würden wir relativ schnell die Suche nach dem Namen an Hand der Telefonnummer durchführen können. Allerdings wäre eine Suche nach welche Telefonnummer hat Person X wieder langsam weil der Name nicht indiziert wäre. Es müssten also mehrere Indizes auf der Tabelle angelegt werden. Es kann pro Tabelle aber nur einen Clustered Index geben. Dafür gibt es den Nonclustered Index. Er kann zusätzlich zum Heap oder dem Clustered Index angelegt werden. Es kann mehrere Nonclustered Index pro Tabelle geben. Somit können wir zusätzliche Spalten indizieren und damit schnell durchsuchbar machen. Das klingt erstmal super, dann kann ja einfach für jede Spalte ein Nonclustered Index angelegt werden und alle Abfragen werden schnell. Vom Prinzip ist das richtig, allerdings erkauft man sich den Vorteil beim Lesen mit dem Nachteil beim Schreiben. Wenn wir einen Datensatz verändern oder einfügen müssen alle betroffenen Indizes mit aktualisiert werden. Das kann bei vielen Indizes länger dauern. Zusätzlich kommt dazu, dass der Nonclustered Index zusätzlichen Speicherplatz belegt, da er eine Kopie der Daten aus dem Clustered Index oder dem Heap ist.

Welche Daten stehen denn im Nonclustered Index. Im Clustered Index stehen alle Daten der Tabelle, da er die Tabelle selber ist. Im Nonclustered Index stehen erstmal nur die Daten nach denen sortiert ist. Also nur die Daten aus dem „Index-Baum“. Jeder Eintrag in einem Nonclustered Index kann eindeutig einem Eintrag im Clustered Index oder im Heap zugeordnet werden. Dafür steht entweder der Schlüssel (beim Clustered Index) oder die Adresse (beim Heap) zusätzlich mit im Nonclustered Index. Was bedeutet das in der Praxis. Gehen wir nochmal zum Beispiel mit den Adressen zurück und gehen von dem Fall aus, dass der Clustered Index auf dem Namen liegt und wir aber eine Suche basierend auf die Telefonnummer machen wollen. Wir legen einen Nonclustered Index auf die Spalte Telefonnummer. In diesem Index sind dann die Telefonnummern sortiert gespeichert und zusätzlich der Name, da er der Schlüssel im Clustered Index der Tabelle ist. Wollen wir nur den Namen an Hand der Telefonnummer rausfinden kommen wir somit schnell zu einem Ergebnis, da wir alle Daten im Nonclustered Index haben und diesen durchsuchen können, da die Telefonnummer der Wert ist nach dem der Index sortiert ist und gleichzeitig ist sie unser „Suchwert“. Wollen wir zusätzlich auch noch die Anschrift haben die in der gleichen Tabelle gespeichert ist, reicht der Nonclustered Index auf der Telefonnummer nicht mehr aus um alle Daten zu bekommen. Wir finden weiterhin relativ schnell die Telefonnummer und den Namen. Allerdings müssen wir jetzt um an die Anschrift zu kommen im Clustered Index nachschlagen im Eintrag mit dem Namen den wir bereits im Nonclustered Index gefunden haben. Diesen Zugriff nennt man dann Key-Lookup. Es wird an Hand eines Keys – in dem Fall der Name – im Clustered Index nachgeschlagen wie die anderen Werte zu diesem Datensatz lauten. Haben wir keinen Clustered Index sondern einen Heap als Basis nennt man es nicht Key Lookup sondern RID Lookup. RID steht hierbei für Row Identifier und ist die physikalische Adresse des Datensatzes.

Diese Lookups sind ein relativ teures Konstrukt. Um diese zu umgehen gibt es noch eine weitere Möglichkeit den Index zu erstellen. Bei einem Nonclustered Index können zusätzliche Spalten zum Index hinzugefügt werden. Diese sind dann nicht Teil der Sortierung. Diese zusätzlichen Spalten sind Kopien der Werte aus der eigentlichen Tabelle, müssen also auch immer aktualisiert werden wenn sich die Daten ändern. Die Entscheidung ob zusätzliche Spalten in die Indizes aufgenommen werden muss immer im Einzelfall getroffen werden. Dem Vorteil, dass der Lookup erspart wird steht der Nachteil, dass zusätzliche Daten gespeichert und aktualisiert werden müssen.

Wie sieht Indexdesign in der Realität nun aus? Mehr dazu in Teil 4 von „Was ist ein Index?“.