Implementierungsprinzip des MySQL-Index

MySQL-Indexdiskussion

In MySQL ist der Index ein Konzept auf Speicher-Engine-Ebene. In diesem Artikel wird hauptsächlich die Indeximplementierung der beiden Speicher-Engines MyISAM und InnoDB erläutert .

MyISAM-Indeximplementierung

Die MyISAM-Engine verwendet B+Tree als Indexstruktur und das Datenfeld des Blattknotens speichert die Adresse des Datensatzes. Die folgende Abbildung ist das schematische Diagramm des MyISAM-Index:

Angenommen, die Tabelle hat insgesamt drei Spalten, siehe Abbildung 8 Der Primärindex einer MyISAM-Tabelle (Primärschlüssel) gibt an. Es ist ersichtlich, dass die Indexdatei von MyISAM nur die Adresse des Datensatzes speichert. In MyISAM gibt es keinen strukturellen Unterschied zwischen dem Primärindex und dem Sekundärindex (Sekundärschlüssel), außer dass der Primärindex einen eindeutigen Schlüssel erfordert, während der Schlüssel des Sekundärindex wiederholt werden kann. Wenn wir einen Hilfsindex für Col2 erstellen, sieht die Struktur dieses Index wie folgt aus:

ist ebenfalls ein B+Baum, und das Datenfeld speichert die Adresse des Datensatz. Daher besteht der Indexabrufalgorithmus in MyISAM darin, zuerst den Index gemäß dem B+Tree-Suchalgorithmus zu durchsuchen. Wenn der angegebene Schlüssel vorhanden ist, wird der Wert seines Datenfelds entnommen und dann der Wert des Datenfelds verwendet die Adresse zum Lesen des entsprechenden Datensatzes.

Die Indexierungsmethode von MyISAM wird auch „nicht geclustert“ genannt. Der Grund, warum sie so genannt wird, besteht darin, sie vom Clustered-Index von InnoDB zu unterscheiden.

InnoDB-Indeximplementierung

Obwohl InnoDB auch B+Tree als Indexstruktur verwendet, unterscheidet sich die spezifische Implementierungsmethode völlig von MyISAM.

Der erste große Unterschied besteht darin, dass die Datendateien von InnoDB selbst Indexdateien sind. Wie wir aus dem Obigen wissen, sind die MyISAM-Indexdatei und die Datendatei getrennt und die Indexdatei speichert nur die Adresse des Datensatzes. In InnoDB ist die Tabellendatendatei selbst eine von B + Tree organisierte Indexstruktur, und das Blattknoten-Datenfeld dieses Baums speichert vollständige Datensätze. Der Schlüssel dieses Index ist der Primärschlüssel der Datentabelle, daher ist die InnoDB-Tabellendatendatei selbst der Primärindex.

Abbildung 10 ist ein schematisches Diagramm des InnoDB-Hauptindex (auch eine Datendatei). Sie können sehen, dass die Blattknoten vollständige Datensätze enthalten. Diese Art von Index wird Clustered-Index genannt. Da die Datendateien von InnoDB selbst nach Primärschlüssel aggregiert werden, erfordert InnoDB, dass die Tabelle einen Primärschlüssel haben muss (MyISAM verfügt möglicherweise nicht über einen). Wenn dieser nicht explizit angegeben wird, wählt das MySQL-System automatisch eine Spalte aus, die die Daten eindeutig identifizieren kann Datensatz als Primärschlüssel. Für diesen Spaltentyp generiert MySQL automatisch ein implizites Feld als Primärschlüssel für die InnoDB-Tabelle. Die Länge dieses Felds beträgt 6 Bytes und der Typ ist lang.

Der zweite Unterschied zum MyISAM-Index besteht darin, dass das Hilfsindexdatenfeld von InnoDB den Wert des Primärschlüssels des entsprechenden Datensatzes anstelle der Adresse speichert. Mit anderen Worten: Alle Sekundärindizes in InnoDB verweisen auf den Primärschlüssel als Datenfeld. Abbildung 11 ist beispielsweise ein in Spalte 3 definierter Hilfsindex:

Hier wird der ASCII-Code englischer Zeichen als Vergleichskriterium verwendet. Die Clustered-Index-Implementierung macht die Suche nach Primärschlüssel sehr effizient, aber für die Suche nach Hilfsindizes muss der Index zweimal abgerufen werden: Rufen Sie zuerst den Hilfsindex ab, um den Primärschlüssel zu erhalten, und verwenden Sie dann den Primärschlüssel, um die Datensätze im Primärindex abzurufen.

Das Verständnis der Indeximplementierung verschiedener Speicher-Engines ist für die korrekte Verwendung und Optimierung von Indizes sehr hilfreich. Wenn man beispielsweise die Indeximplementierung von InnoDB kennt, ist es leicht zu verstehen, warum die Verwendung zu langer Felder nicht empfohlen wird Primärschlüssel, da alle Hilfsindizes alle auf den Primärindex verweisen. Ein langer Primärindex führt dazu, dass der Hilfsindex zu groß wird. Ein weiteres Beispiel: Die Verwendung nichtmonotoner Felder als Primärschlüssel ist in InnoDB keine gute Idee, da die InnoDB-Datendatei selbst ein B+Baum ist und dazu führt, dass die Datendatei die Eigenschaften des B+Baums beibehält Beim Einfügen neuer Datensätze sind häufige Split-Anpassungen sehr ineffizient, und die Verwendung von Feldern mit automatischer Inkrementierung als Primärschlüssel ist eine gute Wahl.

Das Obige ist der Inhalt des Implementierungsprinzips des MySQL-Index. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (m.sbmmt.com)!