Hauptfunktionen von MySQL Innodb: Einfügepuffer

Was ist ein Einfügepuffer?

Der Einfügepuffer, auch Insert-Buffer genannt, ist eine der Hauptfunktionen der InnoDB-Speicher-Engine. Wir verstehen den Insert-Buffer oft als Teil des Pufferpools. Dieses Verständnis ist einseitig. Ein Teil der Informationen des Insert-Buffers befindet sich im Speicher, und der andere Teil existiert auf der physischen Seite wie der Datenseite.

In InnoDB wissen wir, dass die Standardeinfügung in eine Tabelle sehr schnell erfolgt, wenn sie einen automatisch inkrementierenden Primärschlüssel hat. Beachten Sie, dass der Primärschlüssel hier automatisch inkrementiert wird. Wenn er nicht automatisch inkrementiert wird, erfolgt die Einfügung zufällig, was den Aufwand für die Aufteilung der Datenseiten mit sich bringen kann. Auf diese Weise erfolgt die Einfügung nicht sequenziell und wird langsamer. Es gibt noch eine andere Situation: Wenn die von uns eingefügte ID nicht sequenziell, sondern zufällig ist, ist die Einfügegeschwindigkeit nicht besonders hoch, selbst wenn ein automatisch inkrementierter Primärschlüssel vorhanden ist.

Definieren wir eine Tabelle mit einem Primärschlüssel und einem nicht gruppierten Index wie folgt:

Tabelle erstellen t(

eine int auto_increment,

b varchar(30),

Primärschlüssel(a),

Taste (b)

);

Wenn wir Daten gemäß dem Primärschlüssel a einfügen, erfolgt das Einfügen des nicht gruppierten Index, auch Sekundärindex b genannt, nicht sequenziell und die Einfügeleistung nimmt zwangsläufig ab.

Die Speicher-Engine Innodb hat für diese Situation den Insert Buffer entwickelt. Bei Einfüge- oder Aktualisierungsvorgängen für nicht gruppierte Indexe wird nicht jedes Mal in die Indexseite eingefügt, sondern es wird zunächst ermittelt, ob sich die eingefügte nicht gruppierte Indexseite im Pufferpool befindet. Wenn dies der Fall ist, wird sie direkt eingefügt. Wenn nicht, wird sie zunächst in einen Insert Buffer eingefügt, um der Datenbank mitzuteilen, dass dieser nicht gruppierte Index in den Blattknoten eingefügt wurde. Tatsächlich wird er jedoch nicht eingefügt, sondern an einer anderen Stelle gespeichert. Anschließend werden die Zusammenführungsvorgänge für Insert Buffer und Hilfsindex-Blattknoten mit einer bestimmten Häufigkeit und in einer bestimmten Situation ausgeführt. In diesem Fall ist es häufig möglich, das Einfügen mehrerer Datensätze in einem Vorgang zusammenzuführen, was die Leistung des diskreten Einfügens nicht gruppierter Indizes erheblich verbessert.

Was sind die Auslösebedingungen für den Einfügepuffer?

Damit der Einfügepuffer verwendet werden kann, muss er zwei Bedingungen erfüllen: Erstens muss der Index ein sekundärer Index sein und zweitens darf der Index nicht eindeutig sein. Wenn die beiden oben genannten Bedingungen erfüllt sind, kann der Einfügepuffer verwendet werden, um die Einfügevorgangsleistung der Datenbank zu verbessern.

Hierbei ist zu beachten, dass bei einem Absturz der MySQL-Datenbank während der Ausführung einer großen Anzahl von Vorgängen durch das Programm eine große Anzahl von Einfügepuffern vorhanden sein muss, die nicht mit dem tatsächlichen nicht gruppierten Index zusammengeführt wurden, sodass die Wiederherstellung lange dauern kann.

Warum kann es kein eindeutiger Index sein?

Der Grund, warum eindeutige Indizes nicht unterstützt werden, besteht darin, dass, wenn der Hilfsindex ein eindeutiger Index ist, die Eindeutigkeit während des Einfügens überprüft werden muss. Bei der Überprüfung der Eindeutigkeit treten diskrete Lesevorgänge auf, die den Overhead erhöhen, sodass sich der Einfügepuffer nicht lohnt.

Wir können die Nutzung des Einfügepuffers über den InnoDB-Status der Show Engine wie folgt anzeigen:

mysql--root@localhost:dms_alimetadata 20:35:24>>Engine-InnoDB-Status anzeigen\G
-------------------------------------
PUFFER EINFÜGEN UND ADAPTIVER HASH-INDEX
-------------------------------------
Ibuf: Größe 1, freie Listenlänge 0, Segmentgröße 2, 0 Zusammenführungen
Zusammengeführte Operationen:
 0 einfügen, 0 löschen, 0 markieren, 0 löschen
verworfene Operationen:
 0 einfügen, 0 löschen, 0 markieren, 0 löschen

Die Größe stellt die Anzahl der zusammengeführten Datensatzseiten dar, die freie Listenlänge stellt die Länge der freien Liste dar und die Segmentgröße zeigt, dass die aktuelle Einfügepuffergröße 2 * 16 KB beträgt

Einführung in das Konzept des Änderungspuffers

Das neueste MySQL5.7 unterstützt bereits Änderungspuffer. Tatsächlich wurde es in innodb 1.0.x eingeführt. Dieser Änderungspuffer kann als Upgrade des Einfügepuffers verstanden werden, d. h. er kann gängige DML-Sprachen puffern, einschließlich Einfügen, Löschen und Aktualisieren, entsprechend Einfügepuffer, Löschpuffer bzw. Bereinigungspuffer.

Natürlich sind die vom Änderungspuffer verwendeten Objekte immer noch nicht eindeutige Hilfsindizes.

Hier nehmen wir den Aktualisierungsvorgang als Beispiel. Der Aktualisierungsprozess kann in zwei Teile unterteilt werden:

Der erste Teil besteht darin, die delete_mask des Datensatzes als gelöscht zu markieren. Wenn Sie delete_mask nicht kennen, können Sie im Artikel vom 9. April darüber lesen. Der zweite Teil besteht darin, den Datensatz tatsächlich zu löschen.

Der Löschpuffer entspricht dem ersten Aktualisierungsprozess und der Bereinigungspuffer dem zweiten Teil.

In innodb können wir verschiedene Pufferoptionen über den Parameter innodb_change_buffering aktivieren. Die optionalen Werte dieses Parameters sind Einfügungen, Löschungen, Bereinigungen, Änderungen, alle, keine usw. Unter diesen sind Einfügungen, Löschungen und Bereinigungen die oben besprochenen Situationen, Änderungen bedeutet das Einschalten von Einfügungen und Löschungen und alle bedeutet das Einschalten von allen. Die Standardparameter sind wie folgt:

mysql--root@localhost:dms_alimetadata 21:13:37>>Variablen wie „%buffering%“ anzeigen;
        +-------------------------+----------+
| Variablenname | Wert |
+-------------------------+----------+
| innodb_change_buffering | alle |
+-------------------------+----------+
1 Zeile im Satz (0,01 Sek.)

Wir können auch die maximale Speichermenge steuern, die von change_buffer über innodb_change_buffer_max_size verwendet wird. Der Standardwert dieses Parameters ist 25, also 1/4. Das Beispiel lautet wie folgt:

mysql--root@localhost:dms_alimetadata 21:20:52>>Variablen wie „%innodb_change_buffer_max_size%“ anzeigen;
+-------------------------------+----------+
| Variablenname | Wert |
+-------------------------------+----------+
| innodb_change_buffer_max_size | 25 |
+-------------------------------+----------+
1 Zeile im Satz (0,00 Sek.)

In der Ausgabe des obigen Befehls „show engine innodb status“ werden zusammengeführte und verworfene Operationen angezeigt, wobei „insert“ die Anzahl der Puffereinfügeoperationen, „delete“ die Anzahl der Pufferlöschoperationen und „delete“ die Anzahl der Pufferbereinigungsoperationen angibt. Die verworfene Operation gibt an, dass beim Zusammenführen des Änderungspuffers die Tabelle gelöscht wurde und keine Zusammenführung erforderlich ist.

Wie implementiere ich Insert Buffer?

Die Datenstruktur des Einfügepuffers ist ein B+-Baum. Ähnlich wie beim Clustered Index gibt es global nur einen Einfügepuffer-B+-Baum, der für die Einfügepufferung aller Tabellen verantwortlich ist. Dieser B+-Baum wird im gemeinsam genutzten Tabellenbereich platziert, also in der Datei ibdata1. Daher kann beim Versuch, Tabellendaten über die ibd-Datei wiederherzustellen, die Prüftabelle fehlschlagen, da sich die Daten im Hilfsindex der Tabelle möglicherweise noch im Einfügepuffer befinden. Daher ist nach der Wiederherstellung der Datei über die ibd-Datei der Reparaturtabellenvorgang erforderlich, um den Hilfsindex für die Tabelle neu zu erstellen.

Da der Einfügepuffer ein Baum ist, muss er Blattknoten und Nicht-Blattknoten haben. Die Nicht-Blattknoten speichern die Suchschlüsselwerte der Abfrage. Seine Struktur ist wie folgt:

+---------+------------+----------+
| Leerzeichen | Markierung | Wert |
+---------+------------+----------+

Diese Struktur belegt insgesamt 9 Bytes, wobei „space“ die Tabellenbereichs-ID der Tabelle darstellt, in der sich der einzufügende Datensatz befindet. Diese ID ist eine eindeutige ID, die jede Tabelle haben muss. „space“ belegt 4 Bytes, „marker“ belegt 1 Byte, um mit der alten Version des Einfügepuffers kompatibel zu sein, und „offset“ belegt 4 Bytes, um den Offset der Seite anzugeben.

Einfügungsprozess des Hilfsindex?

Wenn ein Hilfsindex in eine Datenseite eingefügt werden soll und sich die Datenseite nicht im Pufferpool befindet, erstellt InnoDB gemäß den Regeln einen Suchschlüssel und fügt den Datensatz dann in den B+-Baum des Einfügepuffers ein. Während des Einfügevorgangs muss der Datensatz auf bestimmte Weise erstellt werden. Das Endergebnis der Einfügung ist ein Datensatz ähnlich dem folgenden:

+---------+------------+-------+------------+------+----------+----------+-------+------+
| Leerzeichen | Markierung | Wert | Metadaten | | | | |
+---------+------------+-------+------------+------+----------+----------+-------+------+

Man kann feststellen, dass es am Ende ein zusätzliches Metadatenfeld und vier weitere Felder gibt. Lassen Sie uns zuerst über das Metadatenfeld sprechen. Es belegt 4 Bytes und wird verwendet, um die Reihenfolge zu sortieren, in der jeder Datensatz in den Einfügepuffer gelangt. Ab der 5. Spalte ist dies der Wert jedes Felds des tatsächlich eingefügten Datensatzes. Im Vergleich zu einem einfachen Datensatz erfordert der Einfügepuffer daher zusätzliche 13 Bytes Overhead.

Um sicherzustellen, dass jeder Merge-Insert-Puffer erfolgreich ist, muss eine spezielle Datenseite eingerichtet werden, um den verfügbaren Speicherplatz jeder Hilfsindexseite zu markieren. Der Typ dieser Datenseite ist eine Insert-Puffer-Bitmap, die den verfügbaren Speicherplatz vieler Hilfsindexseiten verfolgen kann. Werfen wir hier einen kurzen Blick darauf. Im Folgenden wird seine Verwendung erläutert.

Wann soll der Einfügepuffer zusammengeführt werden?

Wir wissen bereits, dass, wenn sich die Hilfsindexseite zum Einfügen von Datensätzen nicht im Pufferpool befindet, der Hilfsindexdatensatz in diesen B+-Baum eingefügt werden muss und dann vom Einfügepuffer mit dem tatsächlichen Hilfsindex zusammengeführt wird. Wann wird also die Zusammenführung durchgeführt?

1. Wenn die Hilfsindexseite in den Pufferpool eingelesen wird

2. Wenn das Einfügepuffer-Bitmap feststellt, dass auf der Hilfsindexseite nicht genügend freier Speicherplatz vorhanden ist, beträgt der allgemeine Schwellenwert 1/32 des Speicherplatzes der Hilfsindexseite.

3. Der Master-Thread führt den Merge-Insert-Buffer-Vorgang einmal pro Sekunde aus

Oben sind die Details des Einfügepuffers, einer Schlüsselfunktion von MySQL Innodb. Weitere Informationen zur Einfügepufferfunktion von Innodb finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!