Die Rolle des Datenbankindex

Die größte Rolle eines Datenbankindex besteht darin, Abfragen zu beschleunigen. Er kann die Anzahl der zu scannenden Datensatzzeilen grundlegend reduzieren. Der Datenbankindex ist außerdem die Datenstruktur speichert a Alle Werte einer Spalte in der Tabelle, das heißt, der Index wird basierend auf einer Spalte in der Datentabelle erstellt.

Der Datenbankindex ist eine Kennung, die an Tabellenfelder angehängt wird, um die Abfragegeschwindigkeit zu erhöhen. Ich habe viele Leute gesehen, die das Konzept des Index mechanisch verstehen und denken, dass das Hinzufügen von Indizes nur Vorteile und keinen Schaden bringt. Hier möchte ich die vorherigen Hinweise zur Indexstudie zusammenfassen:

Verstehen Sie zunächst, warum der Index die Geschwindigkeit erhöht. Wenn die Datenbank eine SQL-Anweisung ausführt, besteht die Standardmethode darin, einen vollständigen Tabellenscan durchzuführen zu den Suchbedingungen, wenn eine passende Bedingung gefunden wird, wird der Suchergebnissammlung hinzugefügt. Wenn wir einem bestimmten Feld einen Index hinzufügen, ermitteln wir bei der Abfrage zunächst die Anzahl der Zeilen mit einem bestimmten Wert in der Indexliste, wodurch die Anzahl der durchquerten übereinstimmenden Zeilen erheblich reduziert wird, sodass die Abfragegeschwindigkeit erheblich erhöht werden kann. Sollte die Indizierung also jederzeit hinzugefügt werden? Hier sind ein paar Gegenbeispiele: 1. Wenn Sie jedes Mal alle Tabellendatensätze abrufen müssen und trotzdem einen vollständigen Tabellenscan durchführen müssen, macht es keinen Sinn, einen Index hinzuzufügen. 2. Für nicht eindeutige Felder wie „Geschlecht“, die eine große Anzahl wiederholter Werte aufweisen, ist das Hinzufügen von Indizes bedeutungslos. 3. Bei Tabellen mit relativ wenigen Datensätzen führt das Hinzufügen von Indizes nicht zu einer Geschwindigkeitsoptimierung, sondern verschwendet Speicherplatz, da Indizes Speicherplatz erfordern und es einen schwerwiegenden Nachteil gibt, dass bei jeder Ausführung von Aktualisieren/Einfügen/Löschen das Feld Alle Indizes vorhanden sein muss für Updates neu berechnet.

Wann ist es also angebracht, einen Index hinzuzufügen? Schauen wir uns ein Beispiel im MySQL-Handbuch an. Hier ist eine SQL-Anweisung:

SELECT c.companyID, c.companyName FROM Companies c, User u WHERE c.companyID = u.fk_companyID AND c.numEmployees > ; = 0 AND c.companyName LIKE '%i%' AND u.groupID IN (SELECT g.groupID FROM Groups g WHERE g.groupLabel = 'Executive')

Diese Anweisung beinhaltet die Verknüpfung von 3 Tabellen. Und enthält viele Suchbedingungen wie Größenvergleich, Like-Matching usw. Die Anzahl der Scanzeilen, die MySQL ohne Index ausführen muss, beträgt 77721876 Zeilen. Nachdem wir Indizes zu den Feldern „companyID“ und „groupLabel“ hinzugefügt haben, beträgt die Anzahl der gescannten Zeilen nur noch 134. In MySQL können Sie die Anzahl der Scans über Explain Select anzeigen. Es ist ersichtlich, dass bei solchen gemeinsamen Tabellen und komplexen Suchbedingungen die durch den Index erzielte Leistungsverbesserung weitaus wichtiger ist als der von ihm belegte Speicherplatz.

Wie wird der Index implementiert? Die meisten DB-Anbieter implementieren Indizes basierend auf einer Datenstruktur – B-Tree. Denn das Merkmal von B-Tree ist, dass es sich zum Organisieren dynamischer Nachschlagetabellen auf direkten Speichergeräten wie Festplatten eignet. Die Definition des B-Baums lautet wie folgt: Ein B-Baum der Ordnung m(m>=3) ist ein m-ary-Baum, der die folgenden Bedingungen erfüllt:

1. Jeder Knoten enthält den folgenden Bereich ( j, p0, k1, p1, k2, p2, ... ki, pi) wobei j die Anzahl der Schlüsselwörter ist, p der untergeordnete Zeiger ist

2. Alle Blattknoten befinden sich auf derselben Ebene und Die Anzahl der Schichten entspricht der Höhe des Baums h

3. Die Anzahl der in jedem Nicht-Wurzelknoten enthaltenen Schlüsselwörter erfüllt [m/2-1]<=j<=m-1

4. Wenn der Baum nicht leer ist, dann hat die Wurzel mindestens 1 Schlüsselwort. Wenn die Wurzel kein Blatt ist, gibt es mindestens 2 Teilbäume und höchstens m Teilbäume

Betrachten Ein Beispiel für einen B-Baum mit 26 englischen Buchstaben: Konstruktion:

Es ist ersichtlich, dass die Komplexität der Suche nach englischen Buchstaben in diesem B-Baum nur O(m) beträgt. Wenn die Datenmenge relativ groß ist, kann eine solche Struktur die Abfragegeschwindigkeit erheblich erhöhen. Es gibt jedoch eine andere Datenstruktur, die Abfragen schneller durchführt als B-Bäume – Hash-Tabellen. Die Definition der Hash-Tabelle lautet wie folgt: Die Menge aller möglichen Schlüsselwörter sei u, die tatsächlich gespeicherten Schlüsselwörter seien mit k bezeichnet und |k| sei viel kleiner als |u|. Die Hash-Methode besteht darin, u über die Hash-Funktion h dem Index der Tabelle T [0, m-1] zuzuordnen, sodass die Schlüsselwörter in u Variablen sind und h das Ergebnis der Funktionsoperation ist, bei dem es sich um die Speicheradresse von handelt entsprechenden Knoten. Somit kann die Suche in O(1)-Zeit abgeschlossen werden.
Allerdings weist die Hash-Tabelle einen Fehler auf, nämlich einen Hash-Konflikt, d. h. zwei Schlüsselwörter berechnen über die Hash-Funktion dasselbe Ergebnis. Angenommen, m und n stellen die Länge der Hash-Tabelle dar, und n/m ist der Füllfaktor der Hash-Tabelle. Je größer der Faktor, desto größer ist die Wahrscheinlichkeit eines Hash-Konflikts.
Aufgrund dieses Fehlers verwendet die Datenbank keine Hash-Tabellen als Standardimplementierung von Indizes. MySQL behauptet, dass es versuchen wird, den festplattenbasierten B-Tree-Index entsprechend dem Ausführungsabfrageformat in einen geeigneten Hash-Index umzuwandeln um weitere Fortschritte zu erzielen. Ich denke, dass andere Datenbankanbieter ähnliche Strategien verfolgen werden. Schließlich sind Suchgeschwindigkeit und Verwaltungssicherheit gleichermaßen wichtige Wettbewerbspunkte.

Das obige ist der detaillierte Inhalt vonDie Rolle des Datenbankindex. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!