Erste Schritte mit Mysql - SQL-Ausführungsprozess

1. Prozess

2. Kernarchitektur

Einfach ausgedrückt ist MySQL hauptsächlich in die Serverschicht und die Speicher-Engine-Schicht unterteilt:

• Serverebene: umfasst hauptsächlich Konnektoren, Abfrage-Cache, Analysator, Optimierer, Executor usw. Alle speicherübergreifenden Engine-Funktionen werden in dieser Ebene implementiert, z. B. gespeicherte Prozeduren, Trigger, Ansichten, Funktionen usw. Es gibt auch ein allgemeines Protokollmodul, das Binglog-Protokollmodul.
• Speicher-Engine: Hauptsächlich verantwortlich für das Speichern und Lesen von Daten, verwendet eine austauschbare Plug-In-Architektur und unterstützt mehrere Speicher-Engines wie InnoDB, MyISAM, Memory usw. Unter diesen verfügt die InnoDB-Engine über ein eigenes Protokollmodul, das Redolog-Modul. Die derzeit am häufigsten verwendete Speicher-Engine ist InnoDB, die seit MySQL 5.5.5 als Standard-Speicher-Engine verwendet wird.

2.1 Einführung in die grundlegenden Komponenten der Serverschicht

1. Anschlüsse

Bei Konnektoren geht es in erster Linie um Authentifizierungs- und Berechtigungsfunktionen, beispielsweise einen Portier auf hoher Ebene.

Es ist hauptsächlich für die Benutzeranmeldung bei der Datenbank und die Benutzeridentitätsauthentifizierung verantwortlich, einschließlich der Überprüfung des Kontokennworts, der Berechtigungen und anderer Vorgänge. Wenn das Kennwort des Benutzerkontos übergeben wird, fragt der Connector alle Berechtigungen des Benutzers in der Berechtigungstabelle ab. Danach hängt die Berechtigungslogikbeurteilung in dieser Verbindung von den zu diesem Zeitpunkt gelesenen Berechtigungsdaten ab. Mit anderen Worten: Solange die Verbindung nicht getrennt wird, ist der Benutzer nicht betroffen, selbst wenn der Administrator die Berechtigungen des Benutzers ändert.

2. Abfrage-Cache (nach MySQL 8.0 entfernt)

Der Abfragecache wird hauptsächlich zum Zwischenspeichern der von uns ausgeführten SELECT-Anweisung und des Ergebnissets der Anweisung verwendet.

Nachdem die Verbindung hergestellt wurde, wird beim Ausführen einer Abfrageanweisung zuerst der Cache abgefragt. MySQL überprüft zunächst, ob das SQL ausgeführt wurde, und speichert es in Form von Schlüssel-Wert im Speicher zwischen. Der Schlüssel ist die Abfrageschätzung und der Wert ist der Ergebnissatz. Wird der Cache-Schlüssel getroffen, wird er direkt an den Client zurückgegeben. Wird er nicht getroffen, werden die nachfolgenden Operationen ausgeführt und die Ergebnisse nach Abschluss für den nächsten Aufruf zwischengespeichert. Natürlich wird bei der tatsächlichen Ausführung der Cache-Abfrage noch einmal geprüft, ob die Berechtigungen des Benutzers vorliegen und ob Abfragebedingungen für die Tabelle vorliegen.

Es wird nicht empfohlen, den Cache für MySQL-Abfragen zu verwenden, da es in tatsächlichen Geschäftsszenarien sehr häufig zu Ungültigkeitserklärungen im Abfragecache kommen kann. Wenn Sie eine Tabelle aktualisieren, werden alle Abfragecaches in dieser Tabelle gelöscht. Für Daten, die nicht häufig aktualisiert werden, ist es dennoch möglich, den Cache zu verwenden.

Daher empfehlen wir in den meisten Fällen nicht, den Abfrage-Cache zu verwenden.

Die Cache-Funktion wurde nach MySQL Version 8.0 gelöscht. Der Beamte glaubte auch, dass diese Funktion nur wenige tatsächliche Anwendungsszenarien hatte, also wurde sie einfach gelöscht.

3. Analysator

Wenn MySQL den Cache nicht erreicht, wird der Analysator aufgerufen, der hauptsächlich zur Analyse des Zwecks der SQL-Anweisung verwendet wird. Der Analysator ist ebenfalls in mehrere Schritte unterteilt:

1. Der erste Schritt ist die lexikalische Analyse. Eine SQL-Anweisung besteht aus mehreren Zeichenfolgen. Zuerst müssen wir Schlüsselwörter extrahieren, wie „Auswählen“, „Abfragetabelle vorschlagen“, „Feldnamen vorschlagen“, „Abfragebedingungen vorschlagen“ und so weiter. Nach Abschluss dieser Vorgänge gelangen Sie zum zweiten Schritt.
2. Der zweite Schritt, die Syntaxanalyse, dient hauptsächlich dazu, festzustellen, ob das von Ihnen eingegebene SQL korrekt ist und ob es der MySQL-Syntax entspricht.

Nach Abschluss dieser beiden Schritte ist MySQL zur Ausführung bereit, aber wie wird es ausgeführt und wie erzielt man die besten Ergebnisse? Hier kommt der Optimierer ins Spiel.

4. Optimierer

Die Rolle des Optimierers besteht darin, den von ihm als optimal erachteten Ausführungsplan auszuführen (der manchmal nicht optimal sein muss. Dieser Artikel enthält eine ausführliche Erläuterung dieses Wissensteils), z. B. wie ein Index ausgewählt wird, wenn mehrere Indizes vorhanden sind, wie die Zuordnungsreihenfolge bei der Abfrage mehrerer Tabellen ausgewählt wird usw.

Man kann sagen, dass nach dem Optimierer die spezifische Ausführung dieser Anweisung bestimmt wurde.

5. Aktuator

Nachdem der Ausführungsplan ausgewählt wurde, ist MySQL bereit, mit der Ausführung zu beginnen. Zunächst wird vor der Ausführung überprüft, ob der Benutzer über die Berechtigung verfügt. Wenn der Benutzer keine Berechtigung hat, wird eine Fehlermeldung zurückgegeben. Wenn der Benutzer über die Berechtigung verfügt, wird die Engine-Schnittstelle aufgerufen und das Ergebnis der Schnittstellenausführung zurückgegeben.

3. Anweisungsanalyse

3.1 Abfrageanweisung

SQL kann in zwei Typen unterteilt werden: Abfrage und Aktualisierung (Hinzufügen, Aktualisieren, Löschen). Lassen Sie uns zunächst die Abfrageanweisung analysieren. Die Anweisung lautet wie folgt:

wähle * aus tb_student A, wobei A.Alter='18' und A.Name='Student';

In Kombination mit der obigen Beschreibung analysieren wir den Ausführungsfluss dieser Anweisung:

Überprüfen Sie zunächst, ob die Anweisung die Berechtigung hat. Wenn nicht, wird direkt eine Fehlermeldung zurückgegeben. Wenn die Berechtigung erteilt ist, wird vor MySQL 8.0 zuerst der Cache abgefragt und mit dieser SQL-Anweisung als Schlüssel geprüft, ob ein Ergebnis im Speicher vorhanden ist. Wenn ja, wird der Cache direkt zwischengespeichert. Wenn nicht, fahren Sie mit dem nächsten Schritt fort.

Durch den Analysator wird eine lexikalische Analyse durchgeführt, um die Schlüsselelemente der SQL-Anweisung zu extrahieren. Beispielsweise ist die obige Anweisung eine Abfrageauswahl, der abzufragende Tabellenname ist tb_student, alle Spalten müssen abgefragt werden und die Abfragebedingung ist die ID dieser Tabelle = „1“. Stellen Sie anschließend fest, ob die SQL-Anweisung syntaktische Fehler enthält, also etwa, ob die Schlüsselwörter korrekt sind etc. Ist die Prüfung in Ordnung, fahren Sie mit dem nächsten Schritt fort.

Im nächsten Schritt bestimmt der Optimierer den Ausführungsplan. Die obige SQL-Anweisung kann zwei Ausführungspläne haben:

a. Fragen Sie zunächst die Studententabelle nach dem Studenten mit dem Namen „Zhang San“ ab und ermitteln Sie dann, ob er 18 Jahre alt ist.
b. Suchen Sie zuerst nach den Schülern, die 18 Jahre alt sind, und suchen Sie dann nach Schülern, deren Name „Zhang San“ ist.

Der Optimierer wählt dann basierend auf seinem eigenen Optimierungsalgorithmus die Lösung mit der besten Ausführungseffizienz aus (der Optimierer glaubt, dass dies möglicherweise nicht immer die beste Lösung ist). Nachdem Sie den Ausführungsplan bestätigt haben, können Sie mit der Ausführung beginnen.

Führen Sie eine Berechtigungsprüfung durch. Wenn keine Berechtigung vorliegt, wird eine Fehlermeldung zurückgegeben. Wenn eine Berechtigung vorliegt, wird die Datenbank-Engine-Schnittstelle aufgerufen und das Ausführungsergebnis der Engine zurückgegeben.

3.2 Update-Anweisung

Oben sehen Sie den Ausführungsprozess einer SQL-Abfrage. Sehen wir uns also an, wie eine Update-Anweisung ausgeführt wird. Die SQL-Anweisung lautet wie folgt:

update tb_student A set A.age='19' where A.name=' 張三';

Lassen Sie uns Zhang Sans Alter ändern. In der tatsächlichen Datenbank wird dieses Altersfeld definitiv nicht festgelegt, sonst werden Sie vom technischen Direktor geschlagen. Tatsächlich folgt diese Anweisung im Wesentlichen dem Prozess der vorherigen Abfrage, aber es ist notwendig, beim Ausführen von Aktualisierungen Protokolle aufzuzeichnen, wodurch das Protokollmodul eingeführt wird. Das in MySQL integrierte Protokollmodul ist binlog (Archivprotokoll), das von allen Speicher-Engines verwendet werden kann. Unsere häufig verwendete InnoDB-Engine verfügt auch über ein Protokollmodul Redo Log (Redo-Log). Wir werden den Ausführungsprozess dieser Anweisung im InnoDB-Modus besprechen. Der Ablauf ist wie folgt:

Fragen Sie zuerst die Daten von Zhang San ab. Wenn ein Cache vorhanden ist, wird dieser auch verwendet.

Holen Sie sich dann die Abfrageanweisung, ändern Sie das Alter auf 19 und rufen Sie die API-Schnittstelle der Engine auf, um diese Datenzeile zu schreiben. Die InnoDB-Engine speichert die Daten im Speicher und zeichnet das Redo-Protokoll auf. Zu diesem Zeitpunkt wechselt das Redo-Protokoll in den Vorbereitungszustand und teilt dem Executor mit, dass die Ausführung abgeschlossen ist und jederzeit übermittelt werden kann.

Nach Erhalt der Benachrichtigung zeichnet der Executor das Binärprotokoll auf und ruft dann die Engine-Schnittstelle auf, um das Redo-Protokoll an den festgeschriebenen Status zu übermitteln.

Update abgeschlossen.

Einige Studenten werden hier sicherlich fragen, warum wir zwei Log-Module brauchen. Können wir nicht ein Log-Modul verwenden?

Dies liegt daran, dass MySQL ursprünglich nicht mit der InnoDB-Engine kompatibel war (die InnoDB-Engine wurde von anderen Unternehmen als Plug-In in MySQL eingefügt). Die native Engine von MySQL ist MyISAM, aber wir wissen, dass das Redo-Log nur der InnoDB-Engine vorbehalten ist und andere Speicher-Engines nicht haben. Dies führt dazu, dass die Absturzsicherheit fehlt (die Absturzsicherheit bedeutet, dass selbst bei einem abnormalen Neustart der Datenbank zuvor übermittelte Datensätze nicht verloren gehen) und Binlog-Protokolle nur zum Archivieren verwendet werden können.

Dies bedeutet nicht, dass es nicht möglich ist, nur ein Protokollmodul zu verwenden, aber die InnoDB-Engine unterstützt Transaktionen über das Redo-Log. Dann fragen sich manche Studenten vielleicht: Kann ich zwei Protokollmodule verwenden, ohne es so kompliziert zu machen? Warum muss Redo Log den Status „Prepare Pre-Commit“ einführen? Hier verwenden wir einen Beweis durch Widerspruch, um zu erklären, warum wir das tun.

Schreiben Sie zuerst das Redo-Log und führen Sie ein direktes Commit durch, dann schreiben Sie das Binlog. Angenommen, die Maschine stürzt nach dem Schreiben des Redo-Logs ab und das Binlog wird nicht geschrieben. Nach dem Neustart der Maschine stellt die Maschine die Daten über das Redo-Log wieder her. Das Binlog zeichnet die Daten zu diesem Zeitpunkt jedoch nicht auf. Wenn die Maschine später gesichert wird, gehen diese Daten verloren. Gleichzeitig gehen diese Daten auch bei der Master-Slave-Synchronisierung verloren.

Schreiben Sie zuerst das Binärprotokoll und dann das Redo-Protokoll. Angenommen, die Maschine startet nach dem Schreiben des Binärprotokolls abnormal neu. Da kein Redo-Protokoll vorhanden ist, kann die Maschine diesen Datensatz nicht wiederherstellen. Das Binärprotokoll enthält jedoch einen anderen Datensatz. Dann führt der gleiche Grund wie oben zu Dateninkonsistenzen.

Wenn die zweiphasige Redo-Log-Commit-Methode angewendet wird, ist die Situation anders. Nach dem Schreiben des Binglogs verhindert das Senden des Redo-Logs das Auftreten der oben genannten Probleme und stellt so die Datenkonsistenz sicher. Die Frage ist also: Gibt es eine Extremsituation? Angenommen, das Redo-Protokoll befindet sich im Pre-Commit-Zustand und das Bing-Protokoll wurde geschrieben. Was passiert, wenn zu diesem Zeitpunkt ein abnormaler Neustart erfolgt? Dies hängt vom Verarbeitungsmechanismus von MySQL ab. Der Verarbeitungsprozess von MySQL ist wie folgt:

Stellen Sie fest, ob das Redo-Protokoll vollständig ist. Wenn dies der Fall ist, führen Sie sofort ein Commit durch.

Wenn sich das Redo-Protokoll im vorab festgeschriebenen, aber noch nicht festgeschriebenen Zustand befindet, wird die Transaktion zurückgesetzt, wenn das Binärprotokoll abgeschlossen ist.

Dadurch wird das Problem der Datenkonsistenz gelöst.

4. Fazit

• MySQL ist hauptsächlich in die Serverschicht und die Engineschicht unterteilt. Die Serverschicht umfasst hauptsächlich Konnektoren, Abfragecache, Analysator, Optimierer, Executor und ein Protokollmodul (Binlog). Dieses Protokollmodul kann von allen Ausführungs-Engines gemeinsam genutzt werden, und Redolog ist nur in InnoDB verfügbar.
• Die Engine-Schicht ist Plug-in-basiert und umfasst derzeit hauptsächlich MyISAM, InnoDB, Memory usw.
• Der SQL-Ausführungsprozess wird in zwei Kategorien unterteilt. Eine Kategorie ist für Abfrageprozesse wie folgt: Berechtigungsprüfung -> Abfrage-Cache -> Analysator -> Optimierer -> Berechtigungsprüfung -> Executor -> Engine
• Der Ausführungsprozess für Update-Anweisungen läuft wie folgt ab: Analyzer ----》Berechtigungsprüfung ----》Executor—》Engine—Redo-Log vorbereiten—》binlog—》Redo-Log-Commit

Dieser Artikel endet hier. Ich hoffe, Sie können den anderen Inhalten auf 123WORDPRESS.COM mehr Aufmerksamkeit schenken!