Diese Seite wurde maschinell übersetzt. Lesen Sie das englische Original. English

IBSurgeon-Bibliothek

Indizes (InterBase und Firebird)

Alexey Kovyazin, letzte Aktualisierung 07-Sep-2005

Das Konzept, das den Indizes zugrunde liegt, ist einfach und anschaulich und ist eine der wichtigsten Grundlagen des Datenbankdesigns. Auf der Basis von Indizes sind viele grundlegende Datenbankobjekte aufgebaut, und darüber hinaus ist die korrekte Verwendung von Indizes der Schlüssel zur Verbesserung der Produktivität von Datenbankanwendungen. Doch was ist ein Index? Ein Index ist ein geordneter Zeiger auf die Datensätze in der Tabelle. Zeiger bedeutet, dass der Index Werte eines oder mehrerer Felder in der Tabelle sowie die Adressen der Datenseiten enthält, auf denen sich diese Werte befinden (Details zu Datenseiten finden Sie im Kapitel “InterBase-Datenbankstruktur”) (Teil 4). Mit anderen Worten: Ein Index besteht aus Paaren von Werten “Feldwert” - “physischer Speicherort dieses Feldes”.

So können wir anhand des Wertes des Feldes (oder der Felder), das im Index enthalten ist, mithilfe des Index schnell die Stelle in der Tabelle finden, an der der Datensatz mit diesem Wert abgelegt ist. Geordnet bedeutet, dass die im Index gespeicherten Feldwerte sortiert sind. Sehr oft wird ein Index mit einem Bibliothekskatalog verglichen, in dem alle Bücher auf Karten erfasst und auf irgendeine Weise geordnet sind: alphabetisch oder nach Themen, und jede Karte enthält die Information, wo genau das jeweilige Buch im Bestand abgelegt ist.

Warum brauchen wir Indizes?

Das Einzige, was Indizes fördern, ist die Beschleunigung des Abrufs von Datensätzen über ihr indexiertes Feld (indexiert - bedeutet im Index enthalten). Die Hauptfunktion von Indizes besteht darin, einen schnellen Datensatzabruf in der Tabelle zu ermöglichen. Jede Verwendung eines Index läuft darauf hinaus.

Wie wird diese Abruffunktion realisiert? Am Eingang dieser Funktion haben wir den Wert des indexierten Feldes (oder mehrerer Felder). Als Ergebnis des Abrufs sollten wir den gesamten Datensatz erhalten, in dem das indexierte Feld einen vorgegebenen Wert hat. Zuerst wird im Index (genauer gesagt, im geordneten Array von Werten des indexierten Feldes) der gewünschte Wert gesucht, dann wird die Adresse der Datenseite entnommen, auf der sich der gewünschte Datensatz befindet, der Server geht zu dieser Seite und liest den gefundenen Datensatz. Das klingt recht umständlich, aber die Suche mit Index ist um ein Vielfaches schneller als die sequenzielle Aufzählung aller Werte aus der Tabelle.

Wenn wir die Analogie zwischen Index und Bibliothekskatalog fortsetzen, sehen wir, dass der Datensatzabruf mit Index der Buchsuche mit Karte sehr ähnlich ist. Wenn wir ein Buch in einem relativ kleinen Katalog (im Vergleich zum gesamten Bibliotheksbestand) finden, erhalten wir sofort die Information, wo genau das Buch aufbewahrt wird, und können direkt dorthin gehen. Die Suche ohne Index kann mit der sequenziellen Aufzählung aller Bücher in der Bibliothek verglichen werden!

Die Aufzählung aller Datensätze in der Tabelle wird als direkte oder natürliche Suche bezeichnet. Wir sollten sagen, dass trotz der Leistungsfähigkeit moderner Computer die natürliche Suche sehr lange dauern kann, wenn die Tabelle eine große Anzahl von Datensätzen enthält.

Wie sind sie organisiert?

Ein Index ist kein Teil der Tabelle, sondern ein separates Objekt, das mit der Tabelle und anderen Datenbankobjekten verbunden ist. Dies ist ein sehr wichtiger Punkt der DBMS-Implementierung, der es ermöglicht, die Informationsspeicherung von ihrer Darstellung zu trennen.

InterBase speichert wie jede andere relationale Datenbank Datensätze in Tabellen in ungeordneter Weise, d.h. es kümmert sich überhaupt nicht darum, wie Datensätze physisch in der Tabelle verteilt sind. Ungeordnete Speicherung bedeutet, dass zwei nacheinander zur Tabelle hinzugefügte Datensätze nicht nebeneinander liegen müssen. Darüber hinaus haben auch die aus der Tabelle extrahierten Daten keine Ordnung, abgesehen von der, die vom Benutzer bei einer Abfrage explizit angegeben werden muss.

Wir können jedoch nicht auf die Ordnung der gespeicherten Daten verzichten: Endbenutzer von Anwendungen möchten die Daten in einer definierten Reihenfolge sehen - zum Beispiel Nachnamen alphabetisch. Indizes lösen das Problem der geordneten Datendarstellung. Die im Index enthaltenen Feldwerte sind geordnet und werden in einer speziellen, für die Suche nach den gewünschten Werten optimierten Ansicht dargestellt (genau das ist für die Erstellung geordneter Sequenzen wesentlich).

Die Trennung der Datenspeicherung von ihrer Darstellung bietet zusätzliche Vorteile gegenüber dem direkten Sortieren - vielleicht müssen Sie die ursprüngliche Tabelle auf verschiedene Weise sortieren. Dann helfen Ihnen Indizes - es kann bis zu 64 Indizes für jede Tabelle geben!

Wenn wir über die Implementierung von Indizes auf physischer Ebene sprechen, stellen sie einen Binärbaum dar, dessen Knoten Paare “Feldwert im Index” - “Datenplatzierung in der Tabelle” sind. Der Abruf des gewünschten Datensatzes im Index erfolgt über den Mechanismus der Hash-Suche - einen der schnellsten Suchalgorithmen.

Indexanwendung

Nachdem nun klar ist, was wir von Indizes verlangen können, ist es an der Zeit, ihre Funktion in einer Datenbank kennenzulernen. Indizes werden in drei Hauptfällen verwendet:

  1. Beschleunigung der Ausführung von Abfragen. Indizes werden für die Felder erstellt, die unter den Suchbedingungen von SQL-Abfragen verwendet werden.

  2. Unterstützung der Eindeutigkeit von Werten in Feldern; eine Primärschlüssel-Constraint (über die im Kapitel “Tabellen. Primärschlüssel” berichtet wurde) verlangt, dass es in der Tabelle keine zwei identischen Werte der Felder gibt, die in einem Primärschlüssel enthalten sind. Um diese Bedingung zu erfüllen, muss beim Einfügen eines neuen Datensatzes nach demselben Wert gesucht werden, der eingefügt wird. Für den Datensatzabruf wird eine spezielle Variante des Index verwendet - ein eindeutiger Index (siehe unten).

  3. Unterstützung der referenziellen Integrität. Fremdschlüssel-Constraints (die im Kapitel “Datenbank-Constraints” behandelt werden) werden verwendet, um zu prüfen, dass die in die Tabelle eingefügten Werte notwendigerweise in einer anderen Tabelle existieren. Beim Erstellen eines Fremdschlüssels wird automatisch ein Index erstellt. Dieser Index wird verwendet, um Abfragen mit Tabellenverbindungen zu beschleunigen sowie um die Bedingungen des Fremdschlüssels zu prüfen. Wir haben kurz alle möglichen Indexanwendungen abgedeckt. Nun werden wir die Besonderheiten jedes Falles genauer betrachten und die am häufigsten gestellten Fragen zur Indexanwendung beantworten.

Beschleunigung der Ausführung von Abfragen mit Indizes

Oben wurde beschrieben, dass die Anwendung von Indizes die Ausführung von Abfragen stark beschleunigen kann. Das ist in den meisten Fällen tatsächlich so, aber es gibt bestimmte Einschränkungen. Zuerst beantworten wir die Frage, die häufig bei denen aufkommt, die sich mit Indizes vertraut gemacht haben. Wenn Indizes den Abruf aus einer Datenbank beschleunigen, warum indexieren wir dann nicht alle Felder in der Tabelle? Es gibt zwei Punkte, die eine allgemeine Indexierung blockieren - Speicherplatz und Kosten bei der Änderung der Daten in der Tabelle. Jeder erstellte Index hat eine Größe, die der Datengröße im indexierten Feld plus der Datengröße der Datensatzplatzierung entspricht. Wenn wir für jedes Feld in der Tabelle Indizes erstellen, ist ihre Gesamtgröße größer als die Datengröße in der Tabelle! Daher führt die Erstellung einer großen Anzahl von Indizes zu einem enormen Verbrauch an Speicherplatz.

Der zweite Punkt ist wichtiger. Das sind die Aufwendungen bei der Änderung der Daten in der Tabelle. In einem relationalen DBMS sind, wie Sie wissen, Datensätze in Tabellen ungeordnet, und folglich erfolgen das Hinzufügen/Löschen von Datensätzen ohne nennenswerte Ressourcenaufwendungen des Servers. Selbst wenn ein Datensatz aus der Mitte einer Datenbank gelöscht wird, gibt es kein Verschieben von Datenmengen, um diese Leere zu füllen - das ist nicht erforderlich: Der Server markiert einfach den leeren Platz und schreibt bei Bedarf etwas dorthin. Was das Hinzufügen betrifft, wird es in den meisten Fällen am Ende der Tabelle ausgeführt. Obwohl der Server die Hauptdaten in der Tabelle bei Änderungen nicht verschiebt, werden die in Indizes gespeicherten Daten bei jedem Hinzufügen/Löschen von Datensätzen neu geordnet! Mit anderen Worten: Der Server muss den Index neu aufbauen, wenn ein Datensatz in der Mitte der Tabelle hinzugefügt wird. Sicherlich ist die Indeximplementierung irgendwie auf häufige Reorganisationen ausgelegt, aber diese Operationen benötigen dennoch Zeit und Prozessorressourcen, und bei einer großen Anzahl von Indizes in der Tabelle kann die Datenänderung darin viel langsamer sein als in derselben Tabelle ohne Indizes!

Dies sind zwei Hauptgründe, die einer allgemeinen Indexierung im Wege stehen. Daneben gibt es noch einige weitere Anmerkungen, die die Indexanwendung einschränken. Die erste ist die 20-%-Regel. Sie besagt, dass, wenn die Abfrage mehr als 20 % der Datensätze aus der Tabelle zurückgibt, die Verwendung eines Index den Datenabruf verlangsamen kann! Sicherlich hängt die Situation von einer konkreten Abfrage und den Bedingungen ab, die für den Abruf festgelegt sind, aber wir sollten uns merken, dass 20 % der Datensätze eine Schwelle sind, ab der die Effizienz der Indexverwendung fraglich wird. Die zweite Anmerkung ist nicht so klar formuliert. Sie hängt mit der Arbeit des InterBase-Optimierers zusammen.

Der Optimierer ist eine Sammlung von Mechanismen, die den Ausführungsplan einer Abfrage entwickeln. Wenn der Benutzer eine SQL-Abfrage an InterBase gibt, legt er fest, was der Server nach der Ausführung der Abfrage zurückgeben soll, definiert aber nicht, WIE der Server die Abfrage ausführen soll. Der Optimierer erstellt auf der Grundlage der gegebenen Abfrage den Ausführungsplan, d.h. woher und in welcher Reihenfolge die Daten für die Ausführung der Abfrage entnommen werden und welche Indizes dabei verwendet werden. Wenn der Server die Abrufbedingungen analysiert (das sind hauptsächlich Teile der Ausdrücke WHERE, ORDER BY usw.), versucht er für jedes in der Bedingung enthaltene Feld, einen Index zu verwenden. Leider ist der Algorithmus zur Erstellung des Plans unvollständig, und der Optimierer verwendet häufig Indizes, die für die konkrete Abfrage nicht sehr effektiv sind, wodurch die Ausführungszeit erheblich verlangsamt werden kann. Daher kann die Erstellung unnötiger Indizes zur Erstellung nichtoptimaler Pläne führen.

Es sollte angemerkt werden, dass dieses Problem im Yaffil-Klon dank der Verwendung moderner Algorithmen zur Planerstellung gelöst ist. Der dritte Fall, in dem ein Index nicht notwendig ist, sind Felder mit einer begrenzten Wertemenge - zum Beispiel das Feld, das die Information über das Geschlecht einer Person speichert und nur zwei mögliche Werte enthält - “F” und “M”; es hat keinen Sinn, dieses Feld zu indexieren. Wir haben also die wichtigsten Einschränkungen bei der Indexerstellung betrachtet. Nun sollten wir das Problem behandeln, wann es notwendig ist, Indizes zu verwenden, um eine Verbesserung der Produktivität zu erreichen. Es gibt 3 Hauptfälle, in denen ein Feld indexiert werden muss:

  • Wenn dieses Feld unter den Abrufbedingungen in Abfragen verwendet wird
  • Wenn Tabellenverbindungen dieses Feld verwenden
  • Wenn dieses Feld in der Sortieranweisung ORDER BY verwendet wird Wenn das Feld in der oben genannten Weise angewendet wird, kann die Erstellung des Index für dieses Feld zu einer Verbesserung der Abfrageproduktivität führen.

Betrachten wir die Syntax zum Erstellen von Indizes. Hier ist das vollständige Format des DDL-Befehls, der das Erstellen von Indizes ermöglicht:

CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]] INDEX index ON table (col [, col …]);

Der minimale Ausdruck zum Erstellen des Index ist der folgende:

CREATE INDEX my_index ON Table_example(ID)

In diesem Beispiel wird ein Index mit dem Namen my_index für die Tabelle Table_example erstellt, und das Feld ID ist das indexierte Feld. Der Index ist aufsteigend, d.h. die Werte darin sind aufsteigend geordnet, sowie nicht eindeutig, und das bedeutet, dass das Feld ID mehrere identische Werte haben kann. Das ist sicherlich das einfachste Beispiel für einen Index - der häufigste Fall. Wie aus der Beschreibung der Syntax ersichtlich ist, kann ein Index nicht nur ein, sondern mehrere Felder enthalten. Ein solcher Index wird verwendet, wenn Abfragen häufig ausgeführt werden und eine Kombination indexierter Felder unter den Such- oder Sortierbedingungen enthalten. Wenn wir zum Beispiel eine Tabelle mit den Feldern Nachname, Vorname und Vatersname haben, wird ein solcher Index bei der Erstellung der Abfrage verwendet, die eine Sortierung nach Nachname, Vorname und Vatersname verwendet. Im Allgemeinen ist es nicht notwendig, die Bedingungen für alle 3 im Index verwendeten Felder anzugeben, um seine Vorteile zu nutzen. Wenn wir das Ergebnis der Abfrage sortieren möchten, wird der Index verwendet, falls das erste Feld in einer Sortierbedingung mit dem ersten Feld im Index übereinstimmt. Zum Beispiel wird unser Index im Fall der Sortierung nach Nachname und Vorname verwendet.

Gemäß der Dokumentation zur Optimierung der Ausführung von Abfragen, die in der Anweisung WHERE eine Verknüpfung von Feldern mit der OR-Bedingung enthalten, sollten wir nicht den aggregierten Index verwenden, sondern mehrere einzelne für alle in der OR-Bedingung enthaltenen Felder.

Zur Frage der Index-Sortierreihenfolge: Sie kann entweder aufsteigend oder absteigend sein. Warum brauchen wir unterschiedliche Sortierreihenfolgen? Offensichtlich für unterschiedliche Sortierungen! Wenn wir Personen nach dem Nachnamen in aufsteigender Reihenfolge sortieren möchten, erstellen wir den aufsteigenden Index (ASC), und wenn in absteigender Reihenfolge (von Z bis A) - dann absteigend! Wenn wir beides möchten, müssen wir beide Indizes erstellen.

Unterstützung der referenziellen Integrität mithilfe von Indizes

Es gibt eine weitere Option in der Indexdefinition - UNIQUE. Wenn wir sie angeben, erlaubt der Index nur das Einfügen eindeutiger Werte in die Tabelle. Tatsächlich ist dies die Grundlage für die Implementierung eindeutiger Schlüssel. Eindeutige Schlüssel werden in Datenbanken häufig verwendet. Das heißt, РК ist ein eindeutiger Schlüssel-Index, aber nicht jeder UK ist РК. Wir haben oben nur über РК gesprochen. Ein Primärschlüssel ist der am häufigsten verwendete Typ eines eindeutigen Schlüssels. Beim Erstellen eines Primärschlüssels für die Tabelle wird automatisch ein eindeutiger Index erstellt. Er erhält einen Namen, der aus RDB$PRIMARYNNN besteht, wobei NNN eine fortlaufende eindeutige Nummer innerhalb einer Datenbank ist. Somit werden zwei wesentliche Einschränkungen der referenziellen Integrität - ein eindeutiger Schlüssel und ein Primärschlüssel - durch die Verwendung eines eindeutigen Index realisiert. Es ist offensichtlich, dass der Begriff der Eindeutigkeit mit dem Begriff des undefinierten Werts unvereinbar ist. Mit anderen Worten: In den Feldern, die in eindeutigen Indizes enthalten sind, dürfen keine Werte vom Typ NULL vorhanden sein. Vor dem Erstellen eines eindeutigen Index für ein Feld muss die Einschränkung NOT NULL festgelegt werden. Wenn der Index für bereits vorhandene Daten erstellt wird, wird beim Erstellen das indizierte Feld auf das Vorhandensein wiederholter Werte geprüft. Wenn es solche enthält, wird Ihnen das Erstellen des Index untersagt.

Neben den Einschränkungen für eindeutige und primäre Schlüssel liegt dem Mechanismus der Indizes die Implementierung einer weiteren Einschränkung der referenziellen Integrität zugrunde - eines Fremdschlüssels. Die Fremdschlüssel-Einschränkung wird für ein oder mehrere Felder einer beliebigen Tabelle festgelegt und verhindert das Einfügen von Werten in diese Felder, die nicht im Primärschlüssel der anderen, übergeordneten Tabelle enthalten sind. Zur Implementierung des Fremdschlüssels, d. h. zur Durchführung der Prüfung, ob ein Wert in der übergeordneten Tabelle vorhanden ist, wird automatisch ein spezieller Index erstellt. Sein Name ist RDB$FOREIGNNN, wobei NNN eine fortlaufende eindeutige Nummer innerhalb einer Datenbank ist.

Warum wird der Mechanismus der Indizes zur Implementierung der Einschränkungen der referenziellen Integrität verwendet? Die Sache ist die, dass Indizes in InterBase eine besondere, bevorzugte Position einnehmen - es wird gesagt, dass sie außerhalb des Kontexts von Transaktionen ausgeführt werden. Dies ist eine sehr wichtige Eigenschaft. Wir werden später über Transaktionen sprechen, im Kapitel, das ihnen gewidmet ist. Jetzt erwähnen wir nur, dass, wenn Indizes außerhalb von Transaktionen liegen, dies bedeutet, dass alle Benutzer, die gleichzeitig mit den Daten in derselben Tabelle arbeiten, die Einschränkungen der referenziellen Integrität einhalten müssen.

Optimierung der Indexproduktivität

Im Titel dieses Teils können wir ein Paradoxon erkennen - Indizes, wie oben erwähnt, sollen die Ausführung von Abfragen beschleunigen, und es stellt sich heraus, dass sie auch optimiert werden müssen! Aber was soll man tun (so ist das Leben) - jemand muss sich um die Indizes kümmern. Was passiert mit Indizes? Warum „verlieren sie ihre Form“? Wir müssen noch einmal sagen, dass Indizes als binärer Baum realisiert werden. Und wenn ein neuer Datensatz zur Tabelle hinzugefügt (aktualisiert, gelöscht - wie Sie möchten) wird, wird ein neuer Zweig zum Baum hinzugefügt. Diese Zweige werden nicht in die Mitte des Baums eingefügt, sondern an die Spitzen anderer Zweige. Allmählich wird der Baum immer verzweigter (oder unbalanciert) und die Suche - weniger effektiv. Der Wiederaufbau des Baums oder (in einigen Fällen) die Neuberechnung der Statistiken kann die Situation verbessern.

In regelmäßigen Abständen ist es erforderlich, den Index neu zu erstellen, um seine Produktivität wiederherzustellen. Die Index-Neuerstellung erfolgt in folgenden Fällen:

  • Beim Wiederaufbau des Index mithilfe des Befehls ALTER INDEX.
  • Beim Löschen und Neuerstellen des Index mithilfe der Befehle DROP INDEX und CREATE INDEX.
  • Beim Sichern und Wiederherstellen aus einer Sicherungskopie mithilfe des Tools gbak.

Außerdem können Sie die Neuberechnung der Statistiken verwenden. Sie müssen jedoch verstehen, dass diese Operation den Indexzustand nicht ändert, sondern den Optimierer lediglich über genaue Informationen zu seinem Zustand informiert, sodass er diesen Index korrekt verwenden kann. Mit anderen Worten: Die Neuberechnung der Statistiken ist keine „Heilung“ des Index, sondern nur eine genaue Diagnose seines Zustands. Betrachten wir alle diese Möglichkeiten der Indexoptimierung genauer. Die Verwendung des Befehls ALTER INDEX hat das folgende Format:

ALTER INDEX name {ACTIVE | INACTIVE};

Hier ist name der Name des Index, und ACTIVE und INACTIVE - zwei Zustände des Index, in die er mithilfe des Befehls ALTER INDEX überführt werden kann. Der Parameter ACTIVE bedeutet, dass der Index aktiv ist und in allen Abfragen und Prozeduren angewendet werden kann. Wenn Sie den Index auf INACTIVE setzen, führt dies zur Deaktivierung seiner Verwendung. Zum Umordnen des Baums müssen zwei Befehle nacheinander ausgeführt werden:

ALTER INDEX name INACTIVE; ALTER INDEX name ACTIVE;

Somit wird der Index neu aufgebaut. Die Verwendung von ALTER INDEX hat eine Reihe von Einschränkungen: Sie können die Indizes, die in primären, eindeutigen und fremden Schlüsseln verwendet werden, nicht neu aufbauen; Sie können den Index nicht neu aufbauen, wenn er derzeit von einer Abfrage verwendet wird; und außerdem ist es zum Ändern des Index erforderlich, die Rechte des Administrators (SYSDBA) zu besitzen oder der Ersteller des jeweiligen Index zu sein.

Die Neuerstellung des Index mithilfe der Befehle DROP INDEX und CREATE INDEX führt zum vollständigen Löschen des Index aus einer Datenbank und anschließend zu seiner Erstellung aus einer leeren Vorlage. Die Syntax des Befehls DROP INDEX ist offensichtlich:

DROP INDEX имя_индекса;

Nach dem Löschen ist es erforderlich, den Index mit demselben Namen und denselben Parametern mithilfe des Befehls CREATE INDEX zu erstellen, dessen Syntax wir bereits betrachtet haben. Die Methode des Wiederaufbaus des Index durch seine vollständige Neuerstellung hat ähnliche Einschränkungen wie die für die Verwendung von ALTER INDEX.

Die dritte Methode des Wiederaufbaus des Index basiert auf der Eigenschaft von Sicherungskopien von InterBase-Datenbanken, die vom Dienstprogramm gbak erstellt werden. Die Sache ist die, dass beim Sichern die im Index enthaltenen Daten nicht in einer Sicherungskopie gespeichert werden, sondern nur die Indexdefinition gespeichert wird. Beim Wiederherstellen aus einer Sicherungskopie wird der Index neu erstellt. Wenn Sie mehr über die Sicherung erfahren möchten, lesen Sie das Kapitel „Sichern und Wiederherstellen aus einer Sicherungskopie“ (Teil 4).

Die vierte Methode zur Verbesserung der Indexproduktivität besteht darin, Statistiken über Indizes mithilfe des Befehls SET STATISTICS zu sammeln. Die Tabellenstatistik ist ein Wert im Bereich von 0 bis 1, dessen Wert von der Anzahl unterschiedlicher Datensätze in der Tabelle abhängt. Der InterBase-Optimierer verwendet Statistiken, um die Effizienz der Anwendung dieses oder jenes Index in einer Abfrage zu bestimmen. Wenn sich die Anzahl der Datensätze in der Tabelle erheblich ändern kann (z. B. aufgrund einer großen Anzahl von Einfügungen oder Entfernungen), kann die Neuberechnung der Statistiken die Produktivität erheblich verbessern. Der Befehl zur Neuberechnung der Statistiken lautet wie folgt:

SET STATISTICS INDEX name;

Hier ist name der Name des Index, für den die Statistik neu berechnet wird. Die Neuberechnung der Statistiken baut den Index nicht neu auf und ist daher von den meisten Einschränkungen befreit, die für die oben beschriebenen Methoden zur Verbesserung der Produktivität festgelegt wurden, mit der Ausnahme, dass nur der Ersteller des Index oder der Systemadministrator (der Benutzer mit dem Namen SYSDBA) Statistiken neu berechnen kann. Korrekte Statistiken ermöglichen es dem Optimierer, eine richtige Entscheidung darüber zu treffen, ob ein Index verwendet werden soll oder nicht.

Wir haben einige Methoden zur Verbesserung der Produktivität von Indizes betrachtet. Mithilfe der Befehle ALTER INDEX und DROP/CREATE INDEX können wir beliebige Indizes neu aufbauen, mit Ausnahme der automatisch erstellten Systemindizes, die zur Gewährleistung der referenziellen Integrität dienen. Wenn Sie diese Indizes neu aufbauen möchten, sollten Sie die Befehle zum Ändern und Erstellen von Tabellen - ALTER TABLE und CREATE TABLE - verwenden, da diese Indizes ein integraler Bestandteil der Tabellenschlüssel sind.