Was ist ein MySQL-Index? Fragen Sie, wenn Sie es nicht verstehen

Überblick

Im Folgenden sind gängige Szenarien aufgeführt, in denen Indizes erstellt werden müssen. Zum Vergleich wird eine Testtabelle erstellt (a hat einen Index, d hat keinen Index):

mysql> create table test( --Testtabelle erstellen-> id int(10) not null AUTO_INCREMENT,
    -> ein int(10) Standardwert null,
    -> b int(10) Standard null,
    -> c int(10) Standard null,
    -> d int(10) Standard null,
    -> Primärschlüssel (ID), --Primärschlüsselindex -> Schlüssel-IDx_a (a), --Hilfsindex -> Schlüssel-IDx_b_c (b,c) --Gemeinsamer Index -> )engine=InnoDB charset=utf8mb4;
Abfrage OK, 0 Zeilen betroffen, 5 Warnungen (0,09 Sek.)
mysql> Prozedur löschen, falls vorhanden, insert_test_data;
Abfrage OK, 0 Zeilen betroffen, 1 Warnung (0,00 Sek.)
mysql> Trennzeichen | --Erstellen Sie eine gespeicherte Prozedur zum Einfügen von 100.000 Daten mysql> create procedure insert_test_data()
    -> beginnen
    -> deklariere i int;
    -> setze i=1;
    -> während(i<=100000) mache
    -> einfügen in test(a,b,c,d)values(i,i,i,i);
    -> setze i=i+1;
    -> Ende während;
    -> Ende |
Abfrage OK, 0 Zeilen betroffen (0,11 Sek.)
mysql> Trennzeichen;
mysql> call insert_test_data(); --Gespeicherte Prozedur ausführen. Abfrage OK, 1 Zeile betroffen (11 Min. 44,13 Sek.)

Beim Abrufen von Daten Indizes zu bedingten Feldern hinzufügen

Aggregatfunktionen fügen Aggregatfeldern Indizes hinzu

Hinzufügen eines Indexes zum Sortierfeld

So verhindern Sie, dass Indizes erneut zur Tabelle hinzugefügt werden

Hinzufügen von Indizes zu verwandten Feldern in verwandten Abfragen

Es ist ersichtlich, dass sich die Abfragegeschwindigkeitsoptimierung nach der Verwendung des Index erheblich verbessert. In diesem Artikel erfahren Sie alles über den MySQL-Index von Grund auf bis hin zur Praxis.

Vom Binärbaum zum B+-Baum

Binärer Baum:

Ein binärer Baum ist eine Baumdatenstruktur mit höchstens zwei untergeordneten Knoten. Ein Knoten ohne übergeordneten Knoten wird als Stammknoten bezeichnet, und ein Knoten ohne untergeordneten Knoten wird als Blattknoten bezeichnet.

Ein binärer Suchbaum ist ein Baum, bei dem das linke Kind jedes Knotens kleiner ist als der Schlüsselwert des aktuellen Knotens und das rechte Kind größer ist als der Schlüsselwert des aktuellen Knotens.

Wie im binären Suchbaum unten gezeigt, benötigen wir nur ⌈ log ( n ) ⌉ ⌈log(n)⌉ ⌈log(n)⌉, also höchstens dreimal, um die Daten abzugleichen, während die lineare Suche im schlimmsten Fall nnn-mal erforderlich ist.

Der Binärbaum kann jedoch zu einer verknüpften Liste degenerieren, wie in der folgenden Abbildung dargestellt, was einem vollständigen Scan entspricht und zu einer geringen Effizienz führt. Um dieses Problem zu lösen, muss sichergestellt werden, dass der Binärbaum immer ausgeglichen ist, d. h. ein ausgeglichener Binärbaum.

Ausgeglichener Binärbaum:

Ein ausgeglichener Binärbaum (AVL-Baum) erfordert, dass der Höhenunterschied zwischen dem linken und rechten Teilbaum jedes Knotens 1 nicht überschreiten kann, um die Eigenschaften eines Binärbaums zu erfüllen. Es sorgt für ein Gleichgewicht in der Baumstruktur. Wenn das Einfügen oder Löschen von Daten zu einem Ungleichgewicht führt, werden Knotenanpassungen vorgenommen, um das Gleichgewicht aufrechtzuerhalten (der spezifische Algorithmus wird weggelassen), um die Suchleistung sicherzustellen.

Ein Knoten in einem ausgeglichenen Binärbaum entspricht einem Schlüsselwert und Daten. Jedes Mal, wenn wir Daten nachschlagen, müssen wir einen Knoten von der Festplatte lesen, was wir als Festplattenblock bezeichnen. Ein Knoten entspricht einem Festplattenblock. Beim Speichern großer Datenmengen verfügt der Baum über eine große Anzahl von Knoten und es werden viele Festplatten-E/A-Vorgänge ausgeführt, die Suchleistung ist jedoch immer noch äußerst niedrig. Dies erfordert einen ausgeglichenen Baum, in dem ein einzelner Knoten mehrere Schlüsselwerte und Daten speichern kann.

B-Baum: B-Baum (Blance Tree) ist ein ausgeglichener Baum, der mehrere Schlüsselwerte und Daten in einem einzigen Knoten speichern kann. Jeder Knoten wird als Seite bezeichnet, d. h. eine Seite mit Daten. Jeder Knoten speichert mehr Schlüsselwerte und Daten, platziert sowohl Schlüsselwerte als auch Daten auf einer Seite, und jeder Knoten hat mehr untergeordnete Knoten. Die Anzahl der untergeordneten Knoten wird im Allgemeinen als Reihenfolge bezeichnet. Die Häufigkeit, mit der der B-Baum die Festplatte bei der Datensuche liest, wird erheblich reduziert und die Suchleistung ist viel höher als die von AVL.

Suchen Sie im B-Baum 3. Ordnung, der in der folgenden Abbildung dargestellt ist, nach Daten mit der ID=42. Stellen Sie zunächst fest, dass der Schlüsselwert 42 auf der ersten Seite größer als 39 ist. Suchen Sie dann die 4. Seite gemäß Zeiger P3 und vergleichen Sie sie. Sie ist kleiner als der Schlüsselwert 45. Suchen Sie dann die 9. Seite gemäß Zeiger P1 und stellen Sie fest, dass dort ein passender Schlüsselwert 42 vorhanden ist, d. h. die entsprechenden Daten wurden gefunden.

B+ Baum:

B+-Baum ist eine weitere Optimierung des B-Baums. Einfach ausgedrückt speichern die Nicht-Blattknoten des B+-Baums keine Daten, sondern nur Schlüsselwerte. Der Grund hierfür ist, dass die Seitengröße in der Datenbank festgelegt ist (InnoDB beträgt standardmäßig 16 KB). Wenn keine Daten gespeichert werden, können mehr Schlüsselwerte gespeichert werden. Je größer die Anzahl der Knoten ist, desto geringer ist auch die Anzahl der Festplatten-E/A-Vorgänge zum Suchen von Daten.

Darüber hinaus entspricht die Reihenfolge des B+-Baums der Anzahl seiner Schlüsselwerte. Wenn ein Knoten 1.000 Schlüsselwerte speichert, sind nur drei Schichten erforderlich, um 1 Milliarde Daten zu speichern. Daher sind im Allgemeinen nur zwei Festplatten-E/A-Vorgänge erforderlich, um nach 1 Milliarde Daten zu suchen (großartig).

Gleichzeitig werden die Daten der Blattknoten des B+-Baums in der richtigen Reihenfolge angeordnet, sodass sich der B+-Baum für die Bereichssuche, die sortierte Suche und die gruppierte Suche eignet (die Daten von B sind auf den Knoten verstreut, was relativ schwierig ist), weshalb MySQL den B+-Baumindex verwendet.

Gruppierter Index

Ein gruppierter Index ist ein Indextyp, der die tatsächlichen Daten auf der Festplatte neu organisiert und nach den Werten einer oder mehrerer angegebener Spalten sortiert. Die physische Reihenfolge der Datenzeilen entspricht der logischen Reihenfolge der Spaltenwerte (normalerweise die Primärschlüsselspalte). In einer Tabelle kann nur ein Clustered-Index vorhanden sein (da er nur in einer physischen Reihenfolge gespeichert werden kann).

InnoDB verwendet einen gruppierten Index. Alle Daten in seiner Tabelle haben einen Primärschlüssel. Auch wenn Sie keinen Primärschlüssel erstellen, wählt InnoDB einen eindeutigen Schlüssel als Primärschlüssel aus. Wenn in der Tabelle kein eindeutiger Schlüssel definiert ist, fügt InnoDB der Tabelle eine versteckte Spalte mit dem Namen row_id als Primärschlüssel hinzu.

Das heißt, wir speichern Daten über InnoDB in einem B+-Baum, und der Schlüsselwert im B+-Baum ist der Primärschlüssel. Dann speichert der Blattknoten im B+-Baum alle Daten in der Tabelle (d. h. die gesamte Datenzeile, die dem Primärschlüssel entspricht). Die Datendatei und die Indexdatei sind dieselbe Datei. Wenn der Index gefunden wird, werden die Daten gefunden, daher nennen wir dies einen gruppierten Index.

Die Aktualisierung gruppierter Indizes ist teuer. Beim Einfügen einer neuen Zeile oder Aktualisieren des Primärschlüssels muss jede aktualisierte Zeile an eine neue Position verschoben werden (da sie nach dem Primärschlüssel sortiert ist). Beim Verschieben von Zeilen können auch Probleme mit der Seitenaufteilung auftreten (d. h. die Seite ist voll). Die Speicher-Engine teilt die Seite in zwei Seiten auf, um Platz zu schaffen, und Seitenaufteilungen beanspruchen mehr Speicherplatz. Das heißt, der Index wird neu geordnet, was zu einer Verschwendung von Ressourcen führt.

Clustered-Indizes eignen sich für Bereichsabfragen. Clustered-Indexabfragen sind sehr schnell und eignen sich besonders für Bereichsprüfungen (zwischen, <, <=, >, >=) oder Group-By- und Order-By-Abfragen. Denn nachdem der gruppierte Index die Zeile mit dem ersten Wert gefunden hat, werden die Zeilen mit den nachfolgenden Indexwerten ohne weitere Suche physisch verbunden, wodurch großflächige Scans vermieden und die Abfragegeschwindigkeit erheblich verbessert wird.

Um beispielsweise Daten mit ID>=19 und ID<30 abzufragen: Normalerweise befindet sich der Stammknoten im Speicher (d. h. Seite 1 ist bereits im Speicher). Suchen Sie zuerst den Schlüsselwert 19 und den entsprechenden Zeiger P2 auf Seite 1, lesen Sie Seite 3 bis P2 (zu diesem Zeitpunkt ist Seite 3 nicht im Speicher und muss von der Festplatte geladen werden), suchen Sie dann den Zeiger P1 des Schlüsselwerts 19 auf Seite 3 und suchen Sie Seite 8 (ebenfalls von der Festplatte in den Speicher geladen). Da die Daten in einer verknüpften Liste sequenziell verknüpft sind, können die dem Schlüsselwert 19 entsprechenden Daten durch binäre Suche gefunden werden.

Nachdem wir den Schlüsselwert 19 gefunden haben, können wir, da es sich um eine Bereichssuche handelt, die verknüpfte Liste im Blattknoten abfragen, die erfüllten Bedingungen der Reihe nach durchlaufen und abgleichen und weiter nach dem Schlüsselwert 21 suchen. Die letzten Daten können unsere Anforderungen immer noch nicht erfüllen. Zu diesem Zeitpunkt verwenden wir den Zeiger P von Seite 8, um die Daten von Seite 9 zu lesen. Seite 9 befindet sich nicht im Speicher und muss auch von der Festplatte geladen und in den Speicher gelesen werden. Dann wird von Zeit zu Zeit abgeleitet, bis der Schlüsselwert 34 übereinstimmt und die Bedingungen nicht erfüllt sind, dann wird es beendet. Dies ist eine Methode zum Suchen von Daten über einen gruppierten Index.

Nicht gruppierter Index

Ein nicht gruppierter Index oder nicht gruppierter Index (Sekundärindex) ist ein B+-Baumindex, der mit anderen Spalten als dem Primärschlüssel als Schlüsselwerte erstellt wird. Die logische Reihenfolge des Index im Index unterscheidet sich von der physischen Speicherreihenfolge der Zeilen auf der Festplatte. Eine Tabelle kann mehrere nicht gruppierte Indizes haben. In InnoDB können mit Ausnahme des Primärschlüsselindex andere Indizes als Hilfsindizes oder Sekundärindizes bezeichnet werden.

MyISAM in MySQL verwendet nicht gruppierte Indizes. Die Speicherreihenfolge von Tabellendaten hat nichts mit Indexdaten zu tun. Blattknoten enthalten Indexfeldwerte und logische Zeiger auf Datenzeilen der Datenseite (die Anzahl der Zeilen entspricht der Datenmenge in der Datentabelle). Wenn Sie also Daten finden möchten, müssen Sie den gruppierten Index basierend auf dem Primärschlüssel durchsuchen. Der Vorgang der Suche nach Daten basierend auf dem gruppierten Index wird als Tabellenrückgabe bezeichnet.

Definieren Sie beispielsweise einen Datentabellentest, der aus test.frm , tsst.myd und test.myi besteht:

• .frm: zeichnet die Tabellendefinitionsanweisungen auf.
• myd: zeichnet die tatsächlichen Tabellendaten auf.
• myi: zeichnet Indexdaten auf

Beim Abrufen von Daten suchen Sie zuerst im Indexbaum test.myi , ermitteln die Zeilenposition von test.myd , wo sich die Daten befinden, und rufen die Daten ab. Daher sind die Indexdateien und Datendateien der MyISAM Engine getrennt und unabhängig. Das Finden des Index bedeutet nicht, die Daten zu finden, d. h. den nicht gruppierten Index.

Eine Tabelle kann mehr als einen nicht gruppierten Index haben. Tatsächlich kann jede Tabelle bis zu 249 nicht gruppierte Indizes haben. Jedes Mal, wenn ein neuer Index für ein Feld erstellt wird, werden jedoch die Daten im Feld kopiert, um den Index zu generieren. Daher erhöht das Hinzufügen eines Index zu einer Tabelle die Größe der Tabelle und nimmt viel Speicherplatz und Arbeitsspeicher in Anspruch. Wenn also Festplattenspeicher und Arbeitsspeicher begrenzt sind, sollte auch die Anzahl der nicht gruppierten Indizes begrenzt werden.

Darüber hinaus muss bei jeder Änderung der Daten in einer Tabelle mit einem nicht gruppierten Index der Index gleichzeitig aktualisiert werden, sodass der nicht gruppierte Index die Einfüge- und Aktualisierungsgeschwindigkeit verlangsamt.

Um beispielsweise nach Daten 36 zu suchen, werden zwei Zahlen verwendet. Die erste Zahl 36 stellt den Schlüsselwert des Index dar und die zweite Zahl 64 stellt den Primärschlüssel der Daten dar. Nachdem wir 36 gefunden haben, erhalten wir die Daten nicht, sondern müssen immer noch zur gruppierten Indextabelle gehen, um die Daten basierend auf dem entsprechenden Primärschlüssel zu finden.

Gemeinsamer Index und Deckungsindex

Ein gemeinsamer Index ist, wie der Name schon sagt, ein Index, der mehrere Spalten einer Tabelle kombiniert. Beim Erstellen eines gemeinsamen Index werden die am häufigsten verwendeten Spalten entsprechend den Geschäftsanforderungen links platziert, da MySQL-Indexabfragen dem Prinzip der Übereinstimmung mit dem am weitesten links stehenden Präfix folgen.

Das Prinzip des ganz links stehenden Präfixabgleichs bedeutet, dass der ganz links stehende zuerst kommt. Beim Abrufen von Daten beginnt der Abgleich ganz links vom gemeinsamen Index. Wenn wir also einen gemeinsamen Index erstellen, wie etwa (a, b, c), ist das gleichbedeutend mit der Erstellung von drei Indizes: (a), (a, b) und (a, b, c). Dies ist das Prinzip des ganz links stehenden Abgleichs.

Ein überdeckender Index ist lediglich ein gemeinsamer Index, der für eine bestimmte Auswahlanweisung spezifisch ist. Das heißt, für eine Select-Anweisung kann ein gemeinsamer Index die Abfrageergebnisse direkt über den Index abrufen, ohne zur Abfragetabelle zurückkehren zu müssen. Dieser gemeinsame Index soll diese Select-Anweisung abdecken. Es kann das Problem der Abfrage nicht gruppierter Index-Back-Tabellen perfekt lösen, allerdings muss bei der Abfrage das Prinzip der Übereinstimmung ganz links des Index beachtet werden.

B+Tree-Index VS Hash-Index

Prinzip:

• B+-Baumindizes müssen möglicherweise mehrere binäre Suchvorgänge durchführen, um die entsprechenden Datenblöcke zu finden.
• Bei der Verwendung der Hash-Indizierung wird die Hash-Funktion verwendet, um den Hash-Wert zu berechnen und die entsprechenden Daten in der Tabelle zu finden.

Hash-Indizes eignen sich für präzise Abfragen gleicher Werte einer großen Anzahl unterschiedlicher Daten, unterstützen jedoch keine Fuzzy-Abfragen oder Bereichsabfragen, können nicht zum Sortieren verwendet werden und unterstützen nicht das am weitesten links stehende Übereinstimmungsprinzip gemeinsamer Indizes. Darüber hinaus treten bei einer großen Anzahl doppelter Schlüsselwerte Hash-Kollisionsprobleme auf.

Normaler Index und eindeutiger Index

Doppelte Werte können in die Felder eines gemeinsamen Index geschrieben werden, doppelte Werte können jedoch nicht in die Felder eines eindeutigen Index geschrieben werden. Stellen Sie zunächst Insert Buffer und Change Buffer vor:

• Puffer einfügen
• Bestimmen Sie zum Einfügen nicht gruppierter Indizes zunächst, ob sich der eingefügte nicht gruppierte Index im Cache-Pool befindet. Wenn es vorhanden ist, wird es direkt eingefügt. Wenn nicht, wird es zuerst in den Einfügepuffer eingefügt und dann wird der Zusammenführungsvorgang des Einfügepuffers und des untergeordneten Knotens der Hilfsindexseite mit einer bestimmten Häufigkeit und Situation gespiegelt. Führen Sie mehrere Einfügungen in einem Vorgang zusammen, um einzelne Festplattenlesevorgänge zu reduzieren. Erfordert, dass der Index sekundär und nicht eindeutig ist.
• Puffer ändern
• Es handelt sich um eine erweiterte Version von Insert Buffer, die neben dem Einfügen auch das Löschen und Ändern unterstützt. Das Nutzungsszenario wird über innodb_change_buffer festgelegt, der standardmäßig auf alle eingestellt ist (es gibt auch Werte wie keine, Einfügungen und Änderungen). Das maximale Speichernutzungsverhältnis wird über innodb_change_buffer_max_size festgelegt (Standard 25 %, Maximalwert 50 %), aber unter der RR-Isolationsstufe kann es zu Deadlocks kommen. Außerdem muss der Index ein Sekundärindex sein und nicht eindeutig.

Der eindeutige Index verwendet den Einfügepuffer, da zur Ermittlung, ob die Eindeutigkeitsbeschränkung verletzt wurde, das direkte Aktualisieren des Speichers schneller geht, wenn alles in den Speicher eingelesen wurde, und die Verwendung des Änderungspuffers nicht erforderlich ist.

Nachdem ein normaler Index den ersten Datensatz gefunden hat, der die Bedingungen erfüllt, sucht er weiter nach dem nächsten Datensatz, bis die Bedingungen nicht mehr erfüllt sind. Bei einem eindeutigen Index endet die Suche, wenn der erste Datensatz gefunden wurde. InnoDB liest die Daten jedoch seitenweise in den Speicher, und die Daten, die die späteren Anforderungen erfüllen, befinden sich möglicherweise alle auf den vorherigen Datenseiten, sodass der Speicherverbrauch mehrerer weiterer Scans normaler Indizes ignoriert werden kann.

Zusammenfassung:

• Wenn Daten geändert werden, können normale Indizes den Änderungspuffer verwenden, eindeutige Indizes jedoch nicht.
• Wenn Daten geändert werden, neigen eindeutige Indizes auf der RR-Isolationsebene stärker zu Deadlocks.
• Bei der Datenabfrage muss ein gemeinsamer Index nach dem Auffinden eines Datensatzes weiterhin den nächsten Datensatz ermitteln, während ein eindeutiger Index direkt nach dem Auffinden des Datensatzes zurückkehrt.
• Wenn es für geschäftliche Zwecke erforderlich ist, dass ein Feld eindeutig ist, verwenden Sie einen normalen Index, sofern der Code garantieren kann, dass ein eindeutiger Wert geschrieben wird. Andernfalls verwenden Sie einen eindeutigen Index.

InnoDB vs. MyISAM

Im Gegensatz dazu können Sie grundsätzlich erwägen, InnoDB als Ersatz für MyISAM zu verwenden. InnoDB ist derzeit auch die Standard-Engine von MySQL, aber Sie müssen bestimmte Probleme speziell analysieren und können die Vor- und Nachteile der beiden je nach tatsächlichen Bedingungen vergleichen und eine geeignetere auswählen.

Lassen Sie uns näher darauf eingehen, warum MyISAM Abfragen schneller sind als InnoDB .

• InnoDB speichert Daten und Indizes im Cache; MyISAM speichert nur Indizes im Cache und reduziert so das Ein- und Auslagern.
• InnoDB-Adressen werden Blöcken und dann Zeilen zugeordnet; MyISAM zeichnet den OFFSET der Datei direkt auf, was die Positionierung beschleunigt.
• InnoDB muss außerdem die MVCC-Konsistenz aufrechterhalten. Vielleicht ist dies in Ihrem Szenario nicht der Fall, aber es muss trotzdem überprüft und aufrechterhalten werden.

MVCC (Multi-Version Concurrency Control)

InnoDB fügt jedem Zeilendatensatz zwei zusätzliche versteckte Werte (Erstellungsversionsnummer und Löschversionsnummer) hinzu, um MVCC zu implementieren, einen zum Aufzeichnen der Zeilendatenerstellungszeit und den anderen zum Aufzeichnen der Zeilendatenablauf-/Löschzeit. InnoDB speichert jedoch nicht den tatsächlichen Zeitpunkt, zu dem diese Ereignisse aufgetreten sind. Stattdessen wird nur die Systemversionsnummer zum Zeitpunkt des Auftretens dieser Ereignisse gespeichert. Wenn Transaktionen erstellt werden und wachsen, zeichnet jede Transaktion zu Beginn ihre eigene Systemversionsnummer auf und jede Abfrage muss prüfen, ob die Versionsnummer jeder Datenzeile mit der Transaktionsversionsnummer übereinstimmt. Das heißt, die Erstellungsversionsnummer jeder Datenzeile ist nicht größer als die Transaktionsversionsnummer, um sicherzustellen, dass die Zeilendaten vor der Erstellung der Transaktion vorhanden sind; die Löschversionsnummer der Zeilendaten ist größer als die Transaktionsversionsnummer oder undefiniert, um sicherzustellen, dass die Zeilendaten nicht vor Beginn der Transaktion gelöscht werden.

Analysieren Sie die Indexnutzung mit „Erläutern“

explain kann die Ausführungseffekte von SQL-Anweisungen zeigen, was dabei helfen kann, bessere Indizes auszuwählen und Abfrageanweisungen zu optimieren. Die Syntax lautet: explain select... from ... [where...]。

Verwenden Sie die im vorherigen Abschnitt beschriebene Testtabelle, um Folgendes zu testen:

mysql> erläutern Sie „select * from test“, wobei a=88888;
+----+----------+----------+---------+------+---------------+-----------+-----------+---------+-------+---------+-------+---------+------+------+------+
| ID | Auswahltyp | Tabelle | Partitionen | Typ | mögliche Schlüssel | Schlüssel | Schlüssellänge | Ref. | Zeilen | gefiltert | Extra |
+----+----------+----------+---------+------+---------------+-----------+-----------+---------+-------+---------+-------+---------+------+------+------+
| 1 | EINFACH | Test | NULL | Ref | idx_a | idx_a | 5 | const | 1 | 100,00 | NULL |
+----+----------+----------+---------+------+---------------+-----------+-----------+---------+-------+---------+-------+---------+------+------+------+
1 Zeile im Satz, 1 Warnung (0,03 Sek.)
mysql> erklären Sie „select b,c from test where b=88888;“
+----+----------+----------+---------+------+---------------+---------+---------+---------+---------+-------+----------+----------+-------------+
| ID | Auswahltyp | Tabelle | Partitionen | Typ | mögliche Schlüssel | Schlüssel | Schlüssellänge | Ref. | Zeilen | gefiltert | Extra |
+----+----------+----------+---------+------+---------------+---------+---------+---------+---------+-------+----------+----------+-------------+
| 1 | SIMPLE | test | NULL | ref | idx_b_c | idx_b_c | 5 | const | 1 | 100.00 | Index wird verwendet |
+----+----------+----------+---------+------+---------------+---------+---------+---------+---------+-------+----------+----------+-------------+
1 Zeile im Satz, 1 Warnung (0,00 Sek.)
mysql> erläutern Sie „select * from test where a=(select a from test where a=88888);
+----+----------+----------+---------+------+---------------+-----------+-----------+--------+-------+-------+---------+---------+
| ID | Auswahltyp | Tabelle | Partitionen | Typ | mögliche Schlüssel | Schlüssel | Schlüssellänge | Ref. | Zeilen | gefiltert | Extra |
+----+----------+----------+---------+------+---------------+-----------+-----------+--------+-------+------+---------+---------+
| 1 | PRIMARY | test | NULL | ref | idx_a | idx_a | 5 | const | 1 | 100,00 | Verwenden von where |
| 2 | UNTERABFRAGE | Test | NULL | Ref | idx_a | idx_a | 5 | const | 1 | 100,00 | Index wird verwendet |
+----+----------+----------+---------+------+---------------+-----------+-----------+--------+-------+-------+---------+---------+
2 Zeilen im Satz, 1 Warnung (0,00 Sek.)

Konzentrieren Sie sich einfach auf diese drei Spalten: select_type , type und extra .

Typ (zeigt an, um welche Tabelle es sich bei dieser Datenzeile handelt)

extra (Details zur Klärung der Anfrage)

Zusammenfassen

Dieser Artikel endet hier. Ich hoffe, er kann Ihnen helfen. Ich hoffe auch, dass Sie mehr Inhalt auf 123WORDPRESS.COM lesen können!