MySQL-Lernzusammenfassung: Ein vorläufiges Verständnis des Architekturdesigns der InnoDB-Speicher-Engine

1. Speicher-Engine

Im letzten Abschnitt haben wir erwähnt, dass der SQL-Ausführungsplan durch die Executor-Komponente vervollständigt wird, die die Speicher-Engine-Schnittstelle aufruft.
Dann können wir Folgendes verstehen: Das MySQL-Datenbankverwaltungssystem ist auf die Speicher-Engine angewiesen, um mit den Festplattendateien zu interagieren, auf denen Daten gespeichert sind.

Also, über welche Speicher-Engines verfügt MySQL?

Die wichtigsten sind MyISAM, InnoDB, Memory und so weiter. Da die InnoDB-Speicher-Engine grundsätzlich im Internet verwendet wird, werde ich als Nächstes mein Wissen über die InnoDB-Speicher-Engine kurz zusammenfassen und die Komponenten der InnoDB-Speicher-Engine kurz vorstellen.

Pufferpool

Wir alle wissen mittlerweile, dass Datenbankdaten in Festplattendateien gespeichert werden.
Können wir die Tabelle also jedes Mal direkt in der Datenträgerdatei hinzufügen, löschen, ändern und abfragen?

Antwort: Nein!

Da die Leistung beim zufälligen Lesen und Schreiben von Festplattendateien sehr schlecht ist, gibt es kein leistungsstarkes MySQL, wenn alle Vorgänge auf der Festplatte ausgeführt werden. MySQL kann keine hohe Parallelität unterstützen und wird im Internet nicht so beliebt sein.

Derzeit ist緩沖池（Buffer Pool） die wichtigste Komponente der InnoDB-Speicher-Engine, eine sehr wichtige Speicherstruktur. Es befindet sich im Speicher und dank der extrem hohen Leistung beim Lesen und Schreiben im Speicher kann MySQL eine hohe Parallelität unterstützen.

Das Nutzungsprinzip des Pufferpools:

Lassen Sie uns zunächst den Prozess des MySQL-Anforderungsempfangs überprüfen.

①. Der MySQL-Worker-Thread überwacht speziell die Verbindung des Datenbankverbindungspools und ruft die SQL-Anweisung in der Verbindung ab, wenn eine Verbindung besteht.
② Anschließend wird die SQL-Anweisung zur Verarbeitung an SQL 接口übergeben und die folgende Reihe von Prozessen wird in der SQL-Schnittstelle ausgeführt.
③.查詢解析器analysiert die SQL-Anweisung und wandelt sie in etwas um, das MySQL verstehen kann.
④.查詢優化器entwickelt dann einen optimalen Ausführungsplan für die SQL-Anweisung.
⑤.執行器ruft die Schnittstelle der Speicher-Engine gemäß dem Ausführungsplan auf.

Das Obige ist eine Zusammenfassung des vorherigen Artikels. Wie führt also die Schnittstelle der Speicher-Engine Hinzufügungen, Löschungen, Änderungen und Abfragen durch? Nehmen Sie den Aktualisierungsvorgang als Beispiel. Die anderen sind ähnlich.
Zunächst ermittelt die Speicher-Engine, ob sich die dem Update-SQL entsprechende Datenzeile im緩沖池（Buffer Pool） befindet. Wenn vorhanden, werden die Daten direkt im緩沖池（Buffer Pool） aktualisiert und anschließend zurückgegeben; wenn nicht vorhanden, werden die Daten aus der Datenträgerdatei in緩沖池（Buffer Pool） gelesen, anschließend wird der Aktualisierungsvorgang ausgeführt und schließlich das Ergebnis zurückgegeben.

3. Logdateien rückgängig machen

Wir alle wissen, dass bei einer Transaktion Datenaktualisierungen jederzeit zurückgesetzt werden können, bevor die Transaktion festgeschrieben wird. Worauf verlassen Sie sich also, um dies zu erreichen?

Verlassen Sie sich auf undo 日志文件.

Das Nutzungsprinzip der Undo-Logdatei:

Nehmen wir als Beispiel die Aktualisierung von Daten:
Wenn Sie eine Datenzeile mit der ID=100 aktualisieren und den Feldnamen von „Zhang San“ in „Li Si“ ändern, werden die beiden Schlüsselinformationen „ID=10“ und „Name=Zhang San“ in undo 日志文件geschrieben.
Wenn Sie eine Transaktion vor dem Festschreiben zurücksetzen müssen, finden Sie diese beiden Schlüsselwörter in undo 日志文件und können anschließend den Aktualisierungsvorgang zurücksetzen.

4. Redo-Log-Puffer

Wie oben erwähnt, werden alle Hinzufügungs-, Lösch-, Änderungs- und Abfragevorgänge tatsächlich im Pufferpool ausgeführt, sodass die Änderungen an den Daten nicht sofort in den Festplattendateien implementiert werden.

Daher stellt sich hier folgende Frage: Was passiert, wenn MySQL abstürzt, bevor die fehlerhaften Daten im Pufferpool wieder in die Datenträgerdatei zurückgeschrieben werden?
Derzeit stellt die InnoDB-Speicher-Engine eine sehr wichtige Komponente bereit, nämlich die redo log buffer . Sie ist auch ein Puffer im Speicher.

Das Nutzungsprinzip des Redo-Log-Puffers:

Am Beispiel des obigen Aktualisierungsvorgangs werden beim Aktualisieren der Daten die Schlüsselinformationen der Datenaktualisierung aufgezeichnet, die dem Redo-Protokoll entsprechen, und dann in redo log buffer geschrieben.

Es gibt jedoch immer noch ein Problem. Wie oben erwähnt, befindet sich redo log buffer auch im Speicher. Wenn MySQL abstürzt, gehen alle Daten im Speicher verloren, sodass auch die fehlerhaften Daten im Pufferpool und die Protokolle im redo log buffer verloren gehen.
Dies führt dazu, dass der Client zwar die Meldung „Update erfolgreich“ erhält, die Daten in der Datenbank jedoch trotzdem nicht erfolgreich aktualisiert wurden.

Daher verfügt redo log buffer auch über eine Strategie zum Leeren der Festplatte. Normalerweise werden beim Festschreiben einer Transaktion redo 日志im redo log buffer auf die Festplatte zurückgeschrieben. Sie müssen sich also keine Sorgen machen, dass die Transaktion zwar erfolgreich festgeschrieben wurde, die aktualisierten Daten jedoch möglicherweise verloren gehen. Selbst wenn MySQL abstürzt, bevor die fehlerhaften Daten im緩沖池（Buffer Pool） zurück auf die Festplatte geschrieben werden, gehen die Daten nicht verloren, da MySQL beim Neustart alle vorherigen Aktualisierungen der fehlerhaften Daten anhand redo 日志auf der Festplatte wiederherstellen kann.

Zusammenfassen

Oben finden Sie eine Zusammenfassung der MySQL-Lerninhalte, die Ihnen der Herausgeber vorgestellt hat. Sie vermitteln ein vorläufiges Verständnis des Architekturdesigns der InnoDB-Speicher-Engine. Ich hoffe, es wird Ihnen hilfreich sein!