Grundlegendes zu MySQL-Clusterindizes und wie Clusterindizes wachsen

In dieser Anmerkung beschreiben wir kurz

• Was ist der B+Tree-Index von MySQL?
• Wie wird der gruppierte Index größer?

Wenn man es Stück für Stück betrachtet, ist es eigentlich ganz einfach zu verstehen.

Wenn Sie meine vorherigen Hinweise gelesen haben, müssen Sie wissen, dass MySQL CRUD im Speicher ausführt, d. h. im Pufferpool. Dann wissen Sie auch, dass MySQL die Daten durch E/A-Vorgänge von der Festplatte in den Speicher liest, wenn sich im Speicher keine von MySQL benötigten Daten befinden. Die Leseeinheit ist: Datenseite

Die Länge der allgemeinen Datenseite beträgt wie folgt

Das ist richtig, echte Daten werden in den Datenseiten gespeichert und die Datenseiten werden im Speicher als bidirektional verknüpfte Tabelle organisiert! Wie unten gezeigt

In der Einstellung von B+Tree ist es erforderlich, dass der Primärschlüsselindex erhöht wird, d. h. wenn der Primärschlüsselindex erhöht wird, müssen alle Daten auf der Datenseite rechts größer sein als die Daten auf der Datenseite links. Es ist jedoch offensichtlich, dass das obige Bild nicht übereinstimmt und daher durch Seitenaufteilung wie folgt angepasst werden muss.

OK, denken Sie jetzt zurück, Sie müssen es schon einmal gehört haben: Beim B+Tree-Clusterindex von MySQL speichern nur die Blattknoten echte Daten und die Nicht-Blattknoten speichern Indexdaten und die Blattknoten sind durch eine bidirektionale verknüpfte Liste verbunden.

Das ist richtig, alle Blattknoten des B+Baums sind die Datenseiten in der obigen Abbildung und sie sind tatsächlich durch eine doppelt verknüpfte Liste verknüpft!

Lesen wir weiter. Wenn wir uns nur die doppelt verknüpfte Liste ansehen, die in der obigen Abbildung durch Datenseiten verbunden ist, was passiert, wenn wir die Datenzeile mit der ID=7 abrufen?

Offensichtlich müssen wir den Scan von vorne beginnen!

Dann fragen Sie sich vielleicht: Haben wir nicht gerade gesagt, dass B+Tree einen aufsteigenden Primärschlüssel erfordert? Und es gibt einen Seitenaufteilungsmechanismus, der sicherstellt, dass alle Daten auf der Datenseite rechts größer sind als der Indexwert der Datenseite links davon. Warum nicht eine binäre Suche durchführen?

Antwort: Ja, es ist tatsächlich möglich, eine binäre Suche auf einer einzelnen Datenseite durchzuführen, aber die organisatorische Beziehung zwischen den Datenseiten ist eine verknüpfte Liste, sodass eine Durchquerung von Anfang an unvermeidlich ist.

Und was ist mit MySQL?

Wie unten gezeigt: MySQL abstrahiert ein Indexverzeichnis für viele Datenseiten

Mit diesem Indexverzeichnis wird die Suche auf vielen Datenseiten für uns wesentlich einfacher! Nutzen Sie direkt die Möglichkeit zur binären Suche!

Und dieses Verzeichnis existiert tatsächlich auf der Datenseite. Der Unterschied zum Blattknoten besteht darin, dass es nur Indexinformationen speichert, während der Blattknoten echte Daten speichert?

Die Geburt der Indexseite bedeutet auch, dass der Prototyp von B+Tree geboren wurde!

Wenn Benutzer weiterhin auswählen, erhöht sich die Anzahl der Datenseiten im Pufferpool und auch die Anzahl der Daten auf der Indexseite erhöht sich. Wenn die vorhandene Indexgröße 16 KB (die Kapazität einer Datenseite) überschreitet, muss eine neue Indexseite erstellt werden, um die neuen Indexinformationen zu speichern. Zu diesem Zeitpunkt wird der B+Tree langsam immer dicker.

Dann wissen Sie auch, dass B+Tree eine Variante von B-Tree ist und B-Tree eigentlich ein allgemeiner Begriff für M-Ordnungsbäume wie 2-3-Baum, 2-3-4-Baum usw. sein kann. Wenn die Elemente, die in jedem Knoten gespeichert werden können, die Obergrenze erreichen, wird der Baum höher (wie im vorherigen Artikel erwähnt).

Genau wie auf dem folgenden Bild:

Oben finden Sie detaillierte Informationen zum MySQL-Clusterindex und wie der Clusterindex wächst. Dies ist auf einen Blick verständlich. Weitere Informationen zum MySQL-Clusterindex finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!