Eine Zusammenfassung der Wissenspunkte zur Datenbankindizierung. Alles, was Sie wissen müssen, finden Sie hier.

Ich glaube, jeder ist mit Datenbankindizes vertraut.

Ein Index ist eine Struktur, die die Werte einer oder mehrerer Spalten einer Datenbanktabelle sortiert. Über einen Index kann schnell auf bestimmte Informationen in einer Datenbanktabelle zugegriffen werden. Als Tool zur Unterstützung bei Abfragen kann ein vernünftig gestalteter Index den Abfragedruck auf die Datenbank erheblich reduzieren. Wie wir alle wissen, ist die Datenbank der Kern und der schwächste Teil des Projekts. Wenn der Druck zu groß ist, kann es leicht zu Fehlern und unvorhersehbaren Auswirkungen kommen. Daher muss das Wissenssystem der Indizierung beherrscht werden, unabhängig davon, ob es sich um die tägliche Entwicklung oder um ein Interview handelt.

Natürlich gibt es viele Wissenspunkte zur Indizierung, obwohl es notwendig ist, sie zu beherrschen, und viele Anfänger übersehen sie oft. Aus diesem Grund möchte ich diese Wissenspunkte zusammenfassen. Es ist nicht nur ein Austausch mit den Lesern, sondern auch eine umfassende Rezension für mich selbst. Ich hoffe, es wird Ihnen hilfreich sein.

Okay, kommen wir ohne weitere Umschweife zum Punkt.

Lassen Sie mich zunächst feststellen, dass alle in diesem Artikel indizierten Wissenspunkte auf der MySQL-Datenbank basieren

Vor- und Nachteile von Indizes

Vorteil:

1. Datenabfragen erheblich beschleunigen

2. Ein eindeutiger Index kann die Eindeutigkeit jeder Zeile in der Datenbanktabelle sicherstellen

3. Beschleunigungstabelle Verbindungszeit

Mangel:

1. Das Erstellen und Verwalten von Indizes nimmt Zeit in Anspruch, daher sollte die Anzahl der Indizes nicht zu groß sein.

2. Ein Index ist eine Datenstruktur, die Speicherplatz beansprucht.

3. Beim Aktualisieren der Tabelle muss auch der Index dynamisch verwaltet werden, was die Wartungsgeschwindigkeit verringert

Arten von Indizes

Der Zweck der Indizierung besteht darin, die Abfrageeffizienz zu verbessern. Es gibt jedoch viele Möglichkeiten, die Indizierung zu implementieren. Deshalb wird hier das Konzept des Indexmodells vorgestellt. Hier stellen wir drei Datenstrukturen vor, die häufig zur Indizierung verwendet werden, nämlich Hash-Tabellen, geordnete Arrays und Suchbäume.

Hash-Index

Eine Hash-Tabelle, auch Hash-Tabelle genannt, ist so konzipiert, dass sie mithilfe einer Hash-Funktion den Schlüsselcode dem Speicherort zuordnet, an dem der Wert gespeichert ist. Beim Lesen wird der Schlüsselcode verwendet, um den Speicherort zu finden und direkt zu speichern. Die durchschnittliche Suchkomplexität dieser Datenstruktur beträgt O(1).

Wenn wir beispielsweise eine Tabelle mit Ausweisinformationen und Benutzernamen verwalten und den Namen basierend auf der Ausweisnummer abfragen müssen, könnte der Hash-Index folgendermaßen aussehen:

Der Vorteil dieser Indexstruktur besteht darin, dass sie einzelne Elemente effizient zufällig hinzufügen oder löschen kann. Der Nachteil besteht darin, dass die Elemente in der Hash-Tabelle nicht unbedingt in der richtigen Reihenfolge angeordnet sind. Wenn Sie also Intervallabfragen durchführen möchten, ist dies sehr langsam.

Angenommen, ich möchte alle Benutzer finden, deren ID-Nummern im Bereich [ID_card_n1, ID_card_n3] in der Abbildung liegen, muss ich sie alle scannen.

Daher eignet sich die Hashtabellenstruktur für Szenarien, in denen nur Abfragen mit gleichwertigen Werten erforderlich sind.

Geordnete Array-Indizierung

Geordnete Array-Indizes sind sowohl in Abfrageszenarien mit gleichen Werten als auch mit Intervallen sehr effizient. Nehmen wir die obige Abbildung als Beispiel. Wenn wir zur Implementierung ein geordnetes Array verwenden, würde es folgendermaßen aussehen:

Die Elemente des Arrays sind in der Reihenfolge der ID-Nummer angeordnet. Wenn Sie die Daten abfragen müssen, können Sie die binäre Suchmethode verwenden, um sie schnell abzurufen. Die zeitliche Komplexität beträgt O(logN). Da die Daten in der Reihenfolge angeordnet sind, ist das Abfragen der Daten innerhalb eines bestimmten Bereichs außerdem sehr schnell.

Natürlich liegen auch die Nachteile geordneter Arrays auf der Hand. Genau wie bei ArrayList ist die Suche zwar schnell, aber beim Hinzufügen und Löschen von Elementen müssen möglicherweise alle nachfolgenden Elemente verschoben werden, was ein natürlicher Defekt des Arrays ist. Daher sind geordnete Array-Indizes nur für statische Speicher-Engines geeignet. Wenn Sie beispielsweise alle Bevölkerungsinformationen einer Stadt im Jahr 2017 speichern möchten, wird dieser Datentyp nicht erneut geändert.

Suchbaumindex

Wenn es um Suchbäume geht, dürfte der uns am besten vertraute Suchbaum der binäre Suchbaum sein. Die Charakteristik eines binären Suchbaums ist, dass der linke Sohn jedes Knotens kleiner ist als der übergeordnete Knoten, der übergeordnete Knoten kleiner ist als der rechte Sohn und die linken und rechten Teilbäume ebenfalls binäre Suchbäume sind. Die durchschnittliche Zeitkomplexität beträgt O(log2(n)).

Es verfügt über die Eigenschaften schneller Einfüge- und Löschvorgänge verknüpfter Listen und die Vorteile einer schnellen Suche in Arrays. Da der binäre Suchbaum selbst geordnet ist, unterstützt es gleichzeitig auch die Bereichssuche.

Tatsächlich scheint ein binärer Suchbaum eine gute Wahl für die Indizierung zu sein, ist es aber nicht.

Zunächst müssen wir uns darüber im Klaren sein, dass dieser Baum auf der Festplatte vorhanden ist. Wir müssen die entsprechenden Knoten jedes Mal von der Festplatte lesen. Die Knoten des binären Suchbaums sind jedoch zufällig in der Datei gespeichert, sodass das Lesen eines Knotens möglicherweise eine Festplatten-E/A erfordert. Binäre Suchbäume sind relativ hoch. Beispielsweise hat ein ausgeglichener binärer Baum mit einer Million Elementen eine Höhe von mehr als zehn Schichten. Mit anderen Worten, in den meisten Fällen erfordert das einmalige Abrufen von Daten mehr als zehn Festplatten-E/A. Dieser Aufwand ist zu hoch, daher werden binäre Suchbäume im Allgemeinen nicht als Indizes verwendet.

Damit eine Abfrage so wenig Datenträger wie möglich liest, muss der Abfrageprozess auf so wenig Datenblöcke wie möglich zugreifen, d. h. die Höhe des Baums muss so gering wie möglich sein, d. h. ein Mehrwege-Suchbaum muss verwendet werden. Die InnoDB-Speicher-Engine verwendet diesen Mehrwege-Suchbaum, den wir oft als B+-Baum bezeichnen.

InnoDB-Indexstruktur

InnoDB ist die am häufigsten verwendete Suchmaschine in MySQL. Die zugrunde liegende Indexstruktur verwendet den B+-Baum und alle Daten werden im B+-Baum gespeichert. Jeder Index entspricht einem B+-Baum in InnoDB.

Die Eigenschaften des B+-Baums sind:

• Alle Blattknoten enthalten Informationen zu allen Elementen und Zeiger auf Datensätze, die diese Elemente enthalten, und die Blattknoten selbst sind in aufsteigender Reihenfolge entsprechend der Größe des Schlüsselworts verknüpft.
• Alle Zwischenknotenelemente sind gleichzeitig in untergeordneten Knoten vorhanden und sind die größten (oder kleinsten) Elemente unter den untergeordneten Knotenelementen.
  

Dieser Aufbau hat zwei Vorteile:

• Ein einzelner Knoten kann mehrere Elemente speichern. Mit Ausnahme der Blattknoten enthalten andere Knoten nur Schlüssel und speichern keine Werte. Auf diese Weise kann die Höhe des Baums effektiv reduziert werden, wodurch die Anzahl der Abfrage-E/A-Vorgänge verringert wird.
• Da der Blattknoten gleichzeitig einen Zeiger auf den nächsten Blattknoten enthält, können, wenn bei einer Bereichsabfrage der erste Blattknoten gefunden wird, die nachfolgenden Daten basierend auf dem Zeiger abgefragt werden, ohne vom Stammknoten aus zu durchlaufen. Aus diesem Grund empfehlen viele Experten, den Primärschlüssel der Tabelle selbsterhöhend zu gestalten, da dies die Effizienz von Bereichsabfragen verbessert.
  

Indexklassifizierung

Datenbankindizes können je nach Struktur in gruppierte und nicht gruppierte Indizes unterteilt werden.

Ein Clustered-Index, auch Clustered-Index genannt, erstellt einen B+-Baum entsprechend dem Primärschlüssel jeder Tabelle. Gleichzeitig speichern die Blattknoten die Zeilendatensatzdaten der gesamten Tabelle. Einfach ausgedrückt ist dies das, was wir oft als Primärschlüsselindex bezeichnen. Der über dem Clustered-Index erstellte Index wird als Sekundärindex bezeichnet, und der Zugriff auf Daten mit dem Sekundärindex erfordert immer eine zweite Suche.

Nicht gruppierter Index, auch nicht gruppierter Index, Sekundärindex genannt. Dieser Indextyp speichert Daten und Index getrennt und die Blattknoten der Indexstruktur verweisen auf die entsprechenden Speicherorte der Daten.

Gruppierter Index

InnoDB verwendet einen gruppierten Index, um den Primärschlüssel in einem B+-Baum zu organisieren, und die Zeilendaten werden in den Blattknoten gespeichert. Nehmen wir eine Benutzertabelle an, die die Felder „ID“, „Name“ und „Unternehmen“ enthält.

Das Bild zeigt die Indexstruktur von InnoDB wie folgt:

Wie aus der Abbildung ersichtlich ist, können wir, wenn wir die Bedingung „wobei ID = 14“ verwenden, um nach dem Primärschlüssel zu suchen, den entsprechenden Blattknoten gemäß dem B+-Baumabrufalgorithmus finden und dann die Zeilendaten erhalten.

Wenn Sie eine bedingte Suche in der Spalte „Name“ durchführen, sind zwei Schritte erforderlich: Der erste Schritt besteht darin, „Name“ im Hilfsindex-B+-Baum abzurufen und dessen Blattknoten zu erreichen, um den entsprechenden Primärschlüssel zu erhalten. Der zweite Schritt besteht darin, mit dem Primärschlüssel einen weiteren B+-Baumsuchvorgang im Primärindex-B+-Baum durchzuführen und schließlich den Blattknoten zu erreichen, um die gesamte Datenzeile zu erhalten. (Der entscheidende Punkt ist, dass Sekundärindizes über andere Schlüssel erstellt werden müssen.)

Dies ist die Struktur eines gruppierten Indexes, und der Vertreter eines nicht gruppierten Indexes ist MyISM, was auch eine allgemeine Suchmaschine in MySQL ist.

Nicht gruppierter Index

Die beiden B+-Bäume der nicht gruppierten Indizes sehen nicht anders aus. Die Knotenstrukturen sind genau gleich, aber die gespeicherten Inhalte sind unterschiedlich. Die Knoten des Primärschlüsselindex-B+-Baums speichern den Primärschlüssel und die Knoten des Sekundärschlüsselindex-B+-Baums speichern den Sekundärschlüssel. Der Index selbst speichert keine Daten. Die Daten werden an einem unabhängigen Ort gespeichert. Die Blattknoten dieser beiden B+-Bäume verwenden eine Adresse, um auf die eigentlichen Tabellendaten zu verweisen.

Es scheint, dass die Effizienz nicht gruppierter Indizes höher ist als die gruppierter Indizes, da der B+-Baum nicht zweimal überprüft werden muss. Warum verwendet die am häufigsten verwendete InnoDB-Engine dann immer noch diese Speicherstruktur? Was sind seine Vorteile?

1. Da in einem gruppierten Index Zeilendaten und Blattknoten zusammen gespeichert werden, befinden sich auf derselben Seite mehrere Zeilendaten. Beim Zugriff auf verschiedene Zeilendatensätze derselben Datenseite wurde die Seite in den Puffer geladen. Beim erneuten Zugriff wird der Zugriff im Speicher abgeschlossen, ohne auf die Festplatte zuzugreifen. Auf diese Weise werden der Primärschlüssel und die Zeilendaten zusammen in den Speicher geladen, und die Zeilendaten können sofort zurückgegeben werden, nachdem der Blattknoten gefunden wurde. Wenn die Daten daher nach der Primärschlüssel-ID organisiert sind, können die Daten schneller abgerufen werden.

2. Der Vorteil der Verwendung des Primärschlüssels als „Zeiger“ anstelle des Adresswerts als Zeiger für den Hilfsindex besteht darin, dass der Wartungsaufwand für den Hilfsindex beim Verschieben von Zeilen oder Aufteilen von Datenseiten verringert wird. Die Verwendung des Primärschlüsselwerts als Zeiger führt zwar dazu, dass der Hilfsindex mehr Platz einnimmt, der Vorteil besteht jedoch darin, dass InnoDB den „Zeiger“ im Hilfsindex beim Verschieben von Zeilen nicht aktualisieren muss. **Das heißt, die Position der Zeile (in der Implementierung durch 16K Page lokalisiert) ändert sich, wenn die Daten in der Datenbank geändert werden (die vorherige Aufteilung des B+-Baumknotens und der Seite). Die Verwendung eines gruppierten Index kann sicherstellen, dass der Hilfsindexbaum nicht betroffen ist, unabhängig davon, wie sich die Knoten des Primärschlüssel-B+-Baums ändern.

3. Clustered-Indizes eignen sich für Sortier- und Bereichsabfragen, während nicht-Clustered-Indizes nicht geeignet sind.

Abdeckungsindex

Wenn wir von Hilfsindizes sprechen, können wir auch einen anderen speziellen Index erweitern, nämlich den überdeckenden Index.

Wie oben erwähnt, erfordert der Zugriff auf Daten in einem Clustered-Index eine sekundäre Suche. Dies bedeutet, dass zuerst der Blattknoten des Sekundärschlüssels gefunden, der dem Primärschlüssel entsprechende Knoten ermittelt und dann der Primärschlüsselindex zum Abfragen der Daten verwendet werden muss. Dies ist relativ langsam. Wenn das benötigte Feld tatsächlich bei der ersten Suche ermittelt werden kann, ist es nicht erforderlich, den Primärschlüssel ein zweites Mal zu suchen. Das heißt, es besteht keine Notwendigkeit, „zur Tabelle zurückzukehren“.

Die obige Tabelle hat beispielsweise drei Felder: ID, Name und Unternehmen. Ich habe einen Index zu Name hinzugefügt. Beim Abfragen von Daten schreibe ich die folgende Anweisung:

Wählen Sie den Namen des Benutzers aus, wobei der Name beispielsweise „张%“ lautet.

Da unsere Anweisung indiziert ist und die zurückgegebenen Felder in den Blattknoten vorhanden sind, wird die Tabelle bei der Abfrage nicht zurückgegeben. Wie großartig ~~

Wenn es sich bei dem erforderlichen Feld zufällig um eine Indexspalte handelt, versuchen Sie daher, diese Abfragemethode anstelle von Anweisungen wie select * zu verwenden.

Indextyp

Die oben erwähnte Indexklassifizierung basiert auf der Struktur. Bei der Klassifizierung nach Umfang können Indizes auch in die folgenden Kategorien unterteilt werden:

Normaler Index: Dies ist der grundlegendste Indextyp ohne Einschränkungen wie beispielsweise Eindeutigkeit.

CREATE INDEX INDEX_NAME ON TABLE_NAME(PROPERTY_NAME)

Eindeutiger Index: Er ist grundsätzlich dasselbe wie ein normaler Index, aber alle Indexspalten dürfen nur einmal vorkommen, um die Eindeutigkeit zu wahren.

EINDEUTIGEN INDEX ERSTELLEN: INDEX_NAME FÜR TABLE_NAME (EIGENSCHAFTSNAME)

Primärschlüssel: Wie bei einem eindeutigen Index kann es keine doppelten Spalten geben, aber im Wesentlichen ist ein Primärschlüssel kein Index, sondern eine Einschränkung und muss als „PRIMÄRSCHLÜSSEL“ angegeben werden. Der Unterschied zu einem eindeutigen Index besteht darin:

• Nachdem der Primärschlüssel erstellt wurde, muss er einen eindeutigen Index enthalten, aber der eindeutige Index ist nicht unbedingt der Primärschlüssel.
• Eindeutige Indexspalten erlauben Nullwerte, während Primärschlüsselspalten keine Nullwerte zulassen.
• Wenn die Primärschlüsselspalte erstellt wird, enthält sie standardmäßig einen Nullwert + einen eindeutigen Index.
• Auf einen Primärschlüssel kann von anderen Tabellen als Fremdschlüssel verwiesen werden, auf einen eindeutigen Index hingegen nicht.
• Eine Tabelle kann nur einen Primärschlüssel, aber mehrere eindeutige Indizes haben.
• Der Primärschlüssel eignet sich besser für eindeutige Kennungen, die nicht leicht geändert werden können, wie z. B. automatisch inkrementierte Spalten, ID-Nummern usw.
  

Volltextindex: Der Indextyp eines Volltextindex ist FULLTEXT und kann auf einer Spalte vom Typ VARCHAR oder TEXT erstellt werden. In Versionen vor MySQL 5.6 unterstützt nur die MyISAM-Speicher-Engine die Volltextindizierung. In den Versionen 5.6 und höher unterstützen sowohl die MyISAM- als auch die InnoDB-Speicher-Engine die Volltextindizierung.

Erstellen Sie einen vollständigen Textindex. Indexname für Tabellenname (Eigenschaftsname).

Gemeinsamer Index: Gemeinsamer Index ist keine Art von Indexklassifizierung, sondern ein gemeinsamer Index, der mehrere Felder enthält. Wenn es beispielsweise einen gemeinsamen Index namens index(a, b) gibt, können Sie bei der Suche a and b als Bedingungen verwenden.

Prinzip der Übereinstimmung ganz links

In einem gemeinsamen Index hat der Index ganz links Vorrang und jeder nachfolgende Index, beginnend beim Index ganz links, kann abgeglichen werden. Wenn gleichzeitig eine Bereichsabfrage (>, <, zwischen, wie) gefunden wird, wird der Abgleich beendet.

Wie oben erwähnt, wird bei Index(a, b) oder a allein als Abfragebedingung der Index verwendet, wenn jedoch b allein als Abfragebedingung verwendet wird, wird der Index nicht verwendet.

Oder wenn Sie einen Index in der Reihenfolge (a, b, c, d) erstellen und für die Suche a = 1 und b = 2 sowie c > 3 und d = 4 verwenden, wird der Index für d nicht verwendet, da das Feld c eine Bereichsabfrage ist und die Felder danach nicht mehr übereinstimmen.

Wann wird der Index ungültig?

1. Verwenden Sie Funktionen oder Ausdrücke in Indexspalten, wie diese

Wählen Sie * aus Test, wobei Num + 1 = 5

MySQL kann diese Art von Gleichung nicht lösen. Dies ist ausschließlich das Verhalten des Benutzers. Die Indexspalte sollte als unabhängige Spalte behandelt werden, damit der Index wirksam wird.

2. Es liegt eine NULL-Wert-Bedingung vor

Wählen Sie * vom Benutzer aus, wobei die Benutzer-ID nicht null ist.

Beim Entwurf einer Datenbanktabelle sollten wir versuchen, NULL-Werte zu vermeiden. Wenn die Daten leer sind, können wir einen Standardwert angeben, z. B. 0 oder -1 für numerische Typen und eine leere Zeichenfolge für Zeichentypen.

3. Verwenden Sie oder den Ausdruck als Bedingung. Wenn eine Spalte keinen Index hat, funktionieren die Indizes der anderen Spalten nicht.

Wählen Sie * vom Benutzer aus, wobei Benutzer-ID = 700 oder Benutzername = "Benutzername" ist.

In diesem Fall ist der Index von user_id während der Ausführung ungültig, wenn user_name indiziert ist, aber user_name nicht. Aus diesem Grund sollte während der Entwicklung so wenig wie möglich verwendet werden, es sei denn, beide Felder sind indiziert.

4. Vergleich zwischen Spalten. In einer Tabelle haben zwei Spalten (id und c_id) separate Indizes. Die folgenden Abfragebedingungen verwenden den Index nicht:

Wählen Sie * aus Test, wobei ID = c_id;

5. Konvertierung von Datentypen. Wenn der Spaltentyp ein String ist, müssen die Daten in der Bedingung in Anführungszeichen gesetzt werden, sonst wird der Index nicht verwendet.

Erstelle den Index „idx_user_name“ ON user(user_name).
Wählen Sie * vom Benutzer, wobei Benutzername = 123 ist;

Obwohl im obigen Beispiel ein Index für den Benutzernamen erstellt wird, wird die Bedingung bei der Abfrage nicht als Zeichenfolge behandelt und der Index daher nicht verwendet.

6. NICHT-Bedingung

Wenn die Abfragebedingung nicht erfüllt ist, wird die Indexpositionierung schwierig und der Ausführungsplan neigt möglicherweise eher zu einem vollständigen Tabellenscan. Zu solchen Abfragebedingungen gehören: <>, NOT, in, not exists

Wählen Sie * vom Benutzer, wobei Benutzer-ID<>500 ist;
Wählen Sie * vom Benutzer, wobei Benutzer-ID in (1,2,3,4,5) ist;
Wählen Sie * vom Benutzer, wobei die Benutzer-ID nicht in (6,7,8,9,0) ist;
Wählen Sie * vom Benutzer, wo die Benutzer-ID vorhanden ist (wählen Sie 1 vom Benutzerdatensatz, wo Benutzerdatensatz.Benutzer-ID = Benutzer.Benutzer-ID);

7. Like-Abfragen beginnen mit %

Versuchen Sie bei der unscharfen Suche, nach dem Nachnamen Zhang ein Platzhalterzeichen zu verwenden. Wenn Sie beispielsweise nach Personen mit dem Nachnamen Zhang suchen möchten, können Sie user_name like '張%' verwenden. Auf diese Weise können Sie bei der Indexsuche die Indexspalte von vorne abgleichen. Wenn es sich jedoch um user_name like '%張' handelt, wird die gesamte Tabelle gescannt.

8. Der mehrspaltige Index folgt dem oben erwähnten Übereinstimmungsprinzip ganz links

Wann werden Indizes verwendet?

Wie oben erwähnt, können Indizes zwar die Abfragegeschwindigkeit erhöhen, beanspruchen aber auch Speicherplatz. Daher ist es besser, je mehr Indizes Sie erstellen. Um Indizes effektiv anzuwenden, sollten wir Indizes für die nützlichsten Abfragefelder reservieren. Im Allgemeinen sollten Indizes für diese Felder erstellt werden:

• Primärschlüsselfeld, selbstverständlich;
• Spalten, nach denen häufig gesucht wird, z. B. Felder, die häufig in Where-Bedingungen verwendet werden;
• Die Fremdschlüsselfelder anderer Tabellen können als Bedingungsfelder zum Verbinden von Tabellen verwendet werden, um die Abfrage verbundener Tabellen effektiv zu beschleunigen.
• Felder, die zum Sortieren, für Statistiken oder zum Gruppieren in Abfragen verwendet werden;

Ebenso sollten einige Spalten nicht indexiert werden. Dazu gehören

• Häufig aktualisierte Felder eignen sich nicht zum Erstellen von Indizes, da bei jeder Aktualisierung nicht nur der Datensatz, sondern auch der Index aktualisiert und die Indexdatei gespeichert wird.
• Für Felder, die in der Where-Bedingung nicht verwendet werden, wird kein Index erstellt.
• Da die Tabelle zu wenige Datensätze enthält, muss kein Index erstellt werden.
• Zu Spalten, die als Text- oder Bildtypen definiert sind, sollten keine Indizes hinzugefügt werden. Dies liegt daran, dass das Datenvolumen dieser Spalten entweder recht groß ist oder nur sehr wenige Werte aufweist, was der Verwendung von Indizes nicht förderlich ist.
• Felder mit wiederholten und gleichmäßig verteilten Daten, daher werden Indizes für häufig abgefragte und häufig sortierte Felder erstellt. Beachten Sie, dass einige Daten viele Duplikate enthalten, sodass die Indizierung dieses Felds nicht sehr effektiv ist. Das Feld „Geschlecht“ enthält beispielsweise nur männliche und weibliche Daten und ist daher nicht für die Indizierung geeignet.
  

Stichwort erklären

„explain“ ist ein MySQL-Schlüsselwort, mit dem wir die Leistung der Suchanweisung anzeigen können.

Dies ist die Anzahl der Abfragetabellen mit insgesamt mehr als 30 Millionen Zeilen. Bei so vielen Daten müssen wir bei der Suche Indizes verwenden. Ob der Index wirksam wird, können wir auch mit diesem Schlüsselwort sehen

Sehen Sie, die Anzahl der Suchergebnisse sank augenblicklich auf 16 und der verwendete Index war index_user_id , was beweist, dass unser Index effektiv ist.

Um dies zu erklären, müssen mehrere wichtige Parameter verstanden werden:

id: die Seriennummer der Abfrage

select_type: Der Abfragetyp, der hauptsächlich zwischen normalen Abfragen und komplexen Abfragen wie Union-Abfragen und Unterabfragen unterscheidet.

Typ:

Typ zeigt den Zugriffstyp an, der ein wichtigerer Indikator ist. Die Ergebniswerte sind von gut bis schlecht:

System > const > eq_ref > ref > Volltext > ref_or_null > Index_Merge > eindeutige Unterabfrage > Index_Unterabfrage > Bereich > Index > ALLE

System ist am effizientesten und ALL ist ein vollständiger Tabellenscan. Im Allgemeinen muss die Abfrage mindestens die Bereichsebene erreichen.

Schlüssel:

Zeigt den Schlüssel an, den MySQL tatsächlich zu verwenden beschlossen hat. Wenn kein Index ausgewählt ist, ist der Schlüssel NULL.

Wenn key=primary, bedeutet dies, dass der Primärschlüssel verwendet wird;

key=null bedeutet, dass kein Index verwendet wird.
mögliche Schlüssel:

Gibt an, welchen Index MySQL verwenden kann, um Zeilen in dieser Tabelle zu finden. Wenn leer, gibt es keinen zugehörigen Index. Überprüfen Sie jetzt, ob die Anweisung etwas enthält, das zum Fehlschlagen des Index führt.

Reihen:

Gibt die geschätzte Anzahl der im Ausführungsplan gescannten Zeilen an. Dabei handelt es sich um einen Schätzwert.

Extra:

Wenn „Nur Index“ gewählt wird, bedeutet dies, dass die Informationen nur unter Verwendung der Informationen im Indexbaum abgerufen werden. Dies ist schneller als das Durchsuchen der gesamten Tabelle.

Bei Verwendung auf „Where“ wird die Where-Einschränkung verwendet.

Wenn „Wo unmöglich“ ist, bedeutet das, dass „Wo“ nicht benötigt wird, was normalerweise bedeutet, dass nichts gefunden wurde.

Die Tatsache, dass ein Index verwendet wird, bedeutet, dass unser Index wirksam ist.

Zusammenfassen

Das sind alle wichtigen Punkte zu Indizes. Lassen Sie uns abschließend die Vorsichtsmaßnahmen für Indizes zusammenfassen.

1. Indizes sollten basierend auf der Verwendung von Tabellendaten erstellt werden. Erstellen Sie nicht zu viele Indizes. Im Allgemeinen wird nicht empfohlen, mehr als 6 Indexfelder in einer Tabelle zu haben.

2. Ein gutes Messer sollte dort eingesetzt werden, wo es am meisten gebraucht wird. Es wird häufig für Abfragen verwendet. Es gibt nicht viele doppelte Daten. Der Index ist besser für Felder geeignet, bei denen die Anzahl der Suchzeilen 4 % des Tabellendatenvolumens nicht überschreitet.

3. Achten Sie beim Erstellen eines gemeinsamen Index auf das Übereinstimmungsprinzip ganz links. Denken Sie daran, dass das Feld ganz links ein Pflichtfeld ist. Ich habe in dieser Hinsicht einen großen Verlust erlitten.

4. Verwenden Sie den Ausführungsplan „Explain“, um die Leistung von Abfrageanweisungen zu überprüfen.

siehe:

https://www.jianshu.com/p/fa8192853184

MySQL Praxis 45 Vorlesungen

endlich

Obwohl es sich um grundlegendes Wissen handelt, habe ich einen Tag gebraucht, um es zu organisieren. Mit mehr als 5.000 Wörtern kann man es als soliden Artikel betrachten. Wenn Sie als Leser das Gefühl haben, dass Sie etwas gewonnen haben, hoffe ich, dass Sie mir eine Weiterleitung oder ein „Gefällt mir“ geben können. Ich verlange nicht vier „Gefällt mir“-Angaben, aber ich bin mit zwei oder einem „Gefällt mir“ zufrieden. Ihre kleine Anstrengung ist die Motivation für meine kontinuierliche Arbeit!

Dies ist das Ende der Zusammenfassung der Wissenspunkte zu Datenbankindizes in diesem Artikel. Alles, was Sie wissen müssen, finden Sie hier. Weitere relevante Wissenspunkte zu Datenbankindizes finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!