Zusammenfassung der MySQL InnoDB-Architektur

Einführung

Als Backend-Programmierer haben wir fast täglich mit Datenbanken zu tun. Es gibt viele Datenbanken auf dem Markt, z. B.: Mysql, Oracle, SqlServer usw. Wie stellen unsere Programme also eine Verbindung zur Datenbank her? Das ist der Datenbanktreiber. Verschiedene Datenbanken entsprechen verschiedenen Datenbanktreibern. Wenn wir eine Verbindung zur Datenbank herstellen, registrieren wir zuerst den Datenbanktreiber und stellen dann basierend auf der Datenbankadresse, dem Benutzernamen, dem Kennwort und anderen Informationen eine Verbindung mit der Datenbank her. Wenn Sie Maven zur Verwaltung Ihres Projekts verwenden, wird im Allgemeinen die folgende Konfiguration angezeigt:

<Abhängigkeit>
  <groupId>mysql</groupId>
  <artifactId>mysql-connector-java</artifactId>
  <version>8.0.24</version>
</Abhängigkeit>

Importieren Sie wie oben beschrieben das MySQL-Treiber-JAR-Paket über Maven. Anschließend können Sie die Datenbank über SQL-Anweisungen im Projekt bedienen. Wie wird die Datenbank nach Erhalt der Anforderung ausgeführt? Als nächstes werde ich die MySQL-Datenbank im Detail erklären.

1. Gesamtarchitektur der MySQL-Datenbank

Im Allgemeinen wissen wir, dass nach der Entwicklung des Webprojekts die Projektdateien in ein War-Paket gepackt und dann über den Tomcat-Container veröffentlicht werden können und Benutzer schließlich auf unser System zugreifen können. Wir alle wissen, dass Tomcat gleichzeitigen Zugriff unterstützt. Wenn mehrere Anfragen gleichzeitig die Datenbank bedienen müssen, müssen dann mehrere Anfragen eine Datenbankverbindung herstellen? Das ist definitiv nicht der Fall, da sonst die Effizienz sehr gering wäre. Wäre es notwendig, für jede Anfrage eine Verbindung aufzubauen und diese nach Abschluss der Anfrage wieder zu trennen? Das ist definitiv nicht der Fall. Häufiges Herstellen und Trennen von Verbindungen beeinträchtigt definitiv die Leistung. Wie löst Tomcat dieses Problem? Erinnern Sie sich an das „Pooling“-Konzept, das wir im Zusammenhang mit Thread-Pools erwähnt haben? Ja, es gibt einen Datenbankverbindungspool in Tomcat, also gibt es auch einen entsprechenden Datenbankverbindungspool auf demselben Datenbankserver. Die allgemeine Struktur ist in der folgenden Abbildung dargestellt

SQL-Schnittstelle

Wenn die Anforderung die Datenbank erreicht, wird sie vom Listening-Thread erkannt und dann zur Verarbeitung an die SQL-Schnittstelle übertragen. Die SQL-Schnittstelle wird speziell zum Ausführen von SQL-Anweisungen wie Hinzufügen, Löschen, Ändern und Abfragen verwendet.

Parser

Obwohl SQL-Anweisungen für uns relativ leicht zu verstehen sind, können sie vom MySQL-System nicht direkt verstanden werden. Daher überträgt die SQL-Schnittstelle die SQL-Anweisungen an den Parser. Der Abfrageparser ist für das Parsen der SQL-Anweisungen verantwortlich, d. h. für das Parsen der SQL-Anweisungen gemäß der festgelegten SQL-Syntax und das Verstehen der von SQL auszuführenden Operationen.

Optimierer

Nachdem der Parser die Vorgänge verstanden hat, die die SQL-Anweisung ausführen muss, wählt er mithilfe des Optimierers einen Pfad aus, den er für den besten hält. Generell gibt es mehrere Wege, um zu einem bestimmten Ergebnis zu gelangen. Um beispielsweise die Werte zweier Felder f1 und f2 in Tabelle T abzufragen, die Bedingung C erfüllen, gibt es mindestens zwei mögliche Wege:

1. Filtern Sie zunächst alle Datenzeilen in Tabelle T heraus, die Bedingung C erfüllen, und wählen Sie dann die Werte der Felder f1 und f2 als Ergebnismenge aus.
2. Wählen Sie zuerst alle Werte von f1 und f2 aus und filtern Sie dann die Datenzeilen heraus, die die Bedingung gemäß Bedingung C erfüllen, um einen Ergebnissatz zu bilden.
   

Der Optimierer ermittelt auf Basis unterschiedlicher Strategien den Abfragepfad, den er für optimal hält.

Stellantrieb

Wenn der Optimierer den optimalen Abfragepfad auswählt, kann er nicht das gewünschte Ergebnis erzielen, sodass wir weiterhin einen Executor verwenden müssen. Die Rolle des Executors besteht darin, einen Ausführungsplan basierend auf dem vom Optimierer ausgewählten optimalen Abfragepfad zu generieren und dann kontinuierlich die vom Datenbankspeicher-Engine bereitgestellte Schnittstelle aufzurufen, um den Ausführungsplan der SQL-Anweisung zu vervollständigen.

Speicher-Engine

Datenbanken speichern Daten im Allgemeinen an zwei Orten: im Speicher oder auf der Festplatte. Wenn wir also Daten abfragen, muss der Executor die Festplatte oder den Speicher abfragen? Wie wird der Speicher abgefragt? Wie wird die Festplatte durchsucht? Die Speicherkapazität ist begrenzt. Was sollen wir tun, wenn kein freier Speicherplatz mehr vorhanden ist? Die Lösung für eine Reihe von Problemen ist die Speicher-Engine. MySQL bietet mehrere Speicher-Engines: InnoDB, MyISAM, MEMORY usw. Die gebräuchlichsten sind InnoDB und MyISAM. Sie können die Speicher-Engine der aktuellen MySQL-Datenbank mit dem Befehl „show engines“ anzeigen. In dieser Serie wird hauptsächlich die Speicher-Engine InnoDB analysiert.

Zusammenfassend wird in der folgenden Abbildung ein vollständiger Satz des Ausführungsflusses für SQL-Anweisungen dargestellt.

2. InnoDB-Speicher-Engine-Architektur

Wenn eine SQL-Anweisung nun den oben beschriebenen Prozess durchläuft und die Schnittstelle erreicht, an der der Executor die InnoDB-Speicher-Engine aufruft, wie funktioniert die InnoDB-Speicher-Engine?

Speicherpufferpool

Zunächst stellen wir die erste wichtige Komponente der InnoDB-Speicher-Engine vor: den Speicherpufferpool oder Pufferpool. Dies ist ein Bereich im Speicher, in dem große Datenmengen gespeichert werden, um Vorgänge wie Abfragen und Aktualisierungen zu ermöglichen. Der Zweck dieser Vorgehensweise besteht darin, die Ausführungseffizienz von SQL-Anweisungen zu verbessern. Daher müssen wir klarstellen, dass unsere Abfrage-, Aktualisierungs- und anderen Vorgänge alle im Pufferpool abgeschlossen werden (unabhängig davon, ob die Daten im Pufferpool vorhanden sind. Wenn sie vorhanden sind, führen Sie die Operation direkt aus. Wenn nicht, laden Sie sie vor der Operation von der Festplatte in den Pufferpool).

Undo-Log-Protokolldatei

Studierende, die sich mit Datenbanken auskennen, wissen, dass Datenaktualisierungen normalerweise in einer Transaktion erfolgen. Transaktionen haben vier Hauptmerkmale: ACID, wobei A für Atomizität steht, d. h. die Vorgänge sind entweder vollständig erfolgreich oder schlagen vollständig fehl. Bei Erfolg wird die Transaktion festgeschrieben, bei Fehlschlag wird sie zurückgesetzt. Das Zurücksetzen erfolgt über ein Undo-Log. (Ich wurde einmal danach gefragt, aber ich war so nervös, dass ich es vergessen habe. Es hat eine Weile gedauert, bis es mir klar wurde ...).

Im Allgemeinen aktiviert die MySQL-Datenbank standardmäßig das automatische Transaktions-Commit, sodass wir keine zusätzlichen Vorgänge ausführen müssen. Wir können das automatische Transaktions-Commit deaktivieren, indem wir autocommit = 0 setzen, und das automatische Transaktions-Commit aktivieren, indem wir autocommit setzen. Bei Interesse können Sie es gerne ausprobieren und ein Gefühl dafür bekommen.

Redolog-Protokolldatei

Wie wir bereits erwähnt haben, wird der Aktualisierungsvorgang im Pufferpool, also im Speicher, abgeschlossen. Wenn MySQL nach dem Vorgang abstürzt, gehen die geänderten Daten im Speicher zwangsläufig verloren. Um dieses Problem zu lösen, ist das Redo-Protokoll in der InnoDB-Architektur so konzipiert, dass es aufzeichnet, welche Daten Sie geändert haben. Wenn MySQL abstürzt, können Sie das Redo-Protokoll verwenden, um nach dem Neustart die Daten wiederherzustellen. Allerdings wird das Redo-Log zunächst in den Redo-Log-Puffer im Speicher geschrieben und nicht auf der Festplatte gespeichert, sodass weiterhin die Gefahr eines Datenverlusts besteht. Daher bietet InnoDB mehrere Strategien zum Leeren des Redo-Logs. Sie können die Leerstrategie über innodb_flush_log_at_trx_commit festlegen. Beispielsweise bedeutet innodb_flush_log_at_trx_commit=1, dass das Transaktions-Commit-Log sofort auf die Festplatte geleert wird. Auf diese Weise besteht kein Risiko eines Datenverlusts, die Leistung wird jedoch definitiv beeinträchtigt. Im Allgemeinen können Sie Richtlinien basierend auf Geschäftsanforderungen festlegen.

Binlog-Protokolldatei

Binlog wird auch Archivprotokoll genannt. Anders als Redo-Log ist es für MySQL-Server und nicht spezifisch für InnoDB. Im Allgemeinen stellen Benutzer Daten zu einem bestimmten Zeitpunkt wieder her, führen Master-Slave-Synchronisierung usw. durch, während Redo-Log-Benutzer nach Fehlern eine Wiederherstellung durchführen. Im Allgemeinen werden beim Übermitteln einer Transaktion auch Archivprotokolle übermittelt. Es gibt auch mehrere Strategien zum Leeren der Datenträger für Archivprotokolle. Sync_binlog wird verwendet, um das Leeren der Datenträger nach mehreren Transaktions-Commits zu steuern. Das spezielle sync_binlog=0 bedeutet, dass der Zeitpunkt des Leerens vom Betriebssystem und nicht von MySQL gesteuert wird.

InnoDB-Ausführungsprozess

Nachdem Sie nun mehrere Komponenten der InnoDB-Speicher-Engine vorgestellt haben, nehmen wir an, dass Sie Daten aktualisieren müssen. Wie sollte der Ausführungsprozess in InnoDB aussehen? wie folgt:

1. Wenn die Daten im Pufferpool nicht vorhanden sind, liest der zufällige E/A-Vorgang die Daten von der Festplatte und legt sie im Pufferpool ab.
2. Schreiben Sie ein Undo-Protokoll, um die Daten zurückzusetzen.
3. Aktualisieren Sie die Daten im Pufferpool.
4. Schreiben Sie das Redo-Log in den Redo-Log-Puffer, um Daten zur Fehlerbehebung zu erhalten.
5. Bereiten Sie sich auf das Festschreiben der Transaktion vor und schreiben Sie das Redo-Protokoll entsprechend der Richtlinie auf die Festplatte.
6. Bereiten Sie sich auf das Festschreiben der Transaktion vor und schreiben Sie das Binärprotokoll entsprechend der Richtlinie auf die Festplatte.
7. Schreiben Sie die Binlog-Datei und die Commit-Markierung in die Redo-Log-Datei.
8. Führen Sie die Transaktion durch.
9. Der E/A-Thread im Hintergrund gibt die fehlerhaften Daten im Pufferpool auf die Festplatte ein. (Da im Frühstadium nur die Protokolle im Pufferpool geändert wurden und die Daten auf der Festplatte nicht geändert wurden, handelt es sich bei den Daten im Pufferpool um fehlerhafte Daten für die Festplattendaten.)
   

Der Vorgang ist in der folgenden Abbildung dargestellt:

Oben finden Sie eine detaillierte Zusammenfassung der MySQL InnoDB-Architektur. Weitere Informationen zur MySQL InnoDB-Architektur finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!