Erste Seite Zurück Weiter Letzte Seite Übersicht Grafik
Aufbau
Notizen:
Unangenehmer wird das, wenn ein „H“ eingetragen werden soll. Der Eintrag im Datenbereich ist immer gleich einfach: neue Seite 11 aufmachen, Daten eintragen, fertig. Aber im Index muss das H auf Seite 7 untergebracht werden, die ja voll ist. Dazu werden nicht alle nachfolgenden Indexwerte „weitergeschoben“, denn so könnte sich eine Änderung durch die ganze Indexebene ziehen, was extrem aufwändig werden kann.
Vielmehr wird so genanntes „Page Splitting“ gemacht: Es wird im Index eine neue Seite 12 geöffnet, auf die die 2. Hälfte der alten Indexseite kopiert wird; jetzt kann der Indexwert „H“ einfach eingetragen werden. Natürlich muss die oberste Seite des Index noch angepasst werden. Sollte die übrigens ebenfalls voll sein, so wird dort ebenfalls Page Splitting durchgeführt (der Baum also um eine Ebene tiefer) und eine neue obserste Seite geöffnet.
Auf diese Weise kann es natürlich mit der Zeit passieren, dass der Baum „aus der Balance“ gerät. In einem balancierten Baum („B-Baum“) ist der kürzeste Weg von der Wurzel bis zu einem Blatt um maximal einen Schritt kürzer als der längste. Geraten Index-Bäume aus der Balance, leidet darunter die Performance des Index. Daher müssen Indizes von Zeit zu Zeit neu aufgebaut werden.
In diesem Zusammenhang sei auch der sogenannte Covering Index erwähnt. Betrachten wir die Abfrage: Select Indexfeld FROM Tabelle WHERE IndexFeld = 'M'. Naheliegenderweise wird sich der Optimizer für einen Indexscan entscheiden. Ausgehend von der Kopfseite 9 wird die Indexseite 8 gesucht werden und von dort aus Datenseite 2. Dann kann die Frage mit 'M' beantwortet werden. Aber im Grunde hatten wir die gesamte projizierte Information bereits in der Hand, als wir die Indexseite 8 gelesen hatten (aber tatsächlich erst dann: es könnte ja auch gar keinen Datensatz mit 'M' geben). Ein guter Datenbankserver erkennt diese Situation und geht nicht mehr im Datenbereich suchen: er nutzt die Tatsache aus, dass im Index die gesamte angefragte Information vorlag. Dieses Verhalten – wenn es der Server unterstützt – kann und sollte man sich natürlich zu Nutze machen, indem man für bestimmte, häufig benötigte Anfragen (auf wenige Feldern) einen anderweitig gar nicht benötigten Index aufbauen lässt.
Natürlich muss irgendwann festgestellt werden, ob ein Index für eine bestimmte Anfrage auch benützbar ist, ob es sich um einen Usable Index handelt. Dabei können bessere Datenbankserver übrigens auch folgenden Trick benützen: ein zusammengesetzter Index ist prinzipiell auch für Anfragen benützbar, die nur Teile betreffen, sofern diese sich in ununterbrochener Folge „von links“ bilden lassen. Ein Index auf die Felder (a, b, c) kann also auch für Anfragen auf a & b oder a allein benützt werden. Es brauchen also Indizes für (a,b) oder a allein nicht mehr gebaut zu werden, wenn eine Index für (a,b,c) existieren sollte – im Gegenteil: solche Indizes sollten entfernt werden. Sehr wohl benötigen Anfragen auf b, c oder (b,c) eigene Indizes zu ihrer Beschleunigung.
Beispiel: Es existiere ein Index auf die Felder (Sozialversicherungsnummer, Geburtsdatum) um für diesen Schlüsselkandidaten einer Personaltabelle Eindeutigkeit durchzusetzen. Um die Datensätze dieser Tabelle nach Geburtsdatum sortiert ausgeben zu lassen, ist dieser Index nicht geeignet. Baut man statt dessen aber einen Index (Geburtsdatum, Sozialversicherungsnummer), so kann dieser genauso gut die Eindeutigkeit der Datensätze feststellen, kann aber zusätzlich benützt werden, um Datensätze nach Geburtsdatum zu sortieren, ohne dass ein Index auf das Feld Geburtsdatum existieren würde! Man kann also durch geschickte Wahl der Felder Indizes einsparen.
Generell gilt das Prinzip: so wenige Indizes auf jede Tabelle wie möglich, aber so viele wie nötig zu bilden. Damit ist gleichzeitig ausgesprochen, dass es für jede Tabelle mehr als einen Index geben kann. Bleibt also nur noch zu erwähnen, dass auch Primärschlüssel- und Eindeutigkeitseinschränkungen (Primary Key- & Unique-Constraints) hinter den Kulissen immer als Index durchgesetzt werden, auch wenn Sie selbst den Befehl „CREATE INDEX“ gar nicht benutzten!