Wie werden SQL-Anweisungen in MySQL ausgeführt?

In diesem Artikel erfahren Sie, wie Sie SQL-Anweisungen in MySQL ausführen. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird Ihnen hilfreich sein.

In diesem Artikel wird der Ausführungsprozess der nächsten SQL-Anweisung in MySQL analysiert, einschließlich des Ablaufs der SQL-Abfrage in MySQL und des Abschlusses der Aktualisierung der SQL-Anweisung.

Vor der Analyse zeige ich Ihnen die Infrastruktur von MySQL. Zu wissen, aus welchen Komponenten MySQL besteht und welche Funktionen diese Komponenten haben, kann uns helfen, diese Probleme zu verstehen und zu lösen.

Eine MySQL-Infrastrukturanalyse

1.1 Übersicht über die grundlegende MySQL-Architektur

Die folgende Abbildung ist ein kurzes Architekturdiagramm von MySQL kann leicht deutlich erkennen, wie die SQL-Anweisung des Benutzers in MySQL ausgeführt wird.

Lassen Sie uns kurz die Grundfunktionen einiger im Bild unten beteiligter Komponenten vorstellen, damit jeder dieses Bild besser verstehen kann. Die Funktionen dieser Komponenten werden in Abschnitt 1.2 ausführlich vorgestellt.

Connector: Die Identitätsauthentifizierung bezieht sich auf Berechtigungen (beim Anmelden bei MySQL).

Abfragecache: Beim Ausführen einer Abfrageanweisung wird zuerst der Cache abgefragt (nach MySQL Version 8.0 entfernt, da diese Funktion nicht sehr praktisch ist).

Analysator: Wenn der Cache nicht erreicht wird, durchläuft die SQL-Anweisung den Analysator. Um es ganz klar auszudrücken: Der Analysator muss zuerst sehen, was Ihre SQL-Anweisung tut, und dann Überprüfen Sie Ihre SQL-Anweisung. Ist die Syntax korrekt?

Optimierer: Gemäß der von MySQL als optimal erachteten Lösung ausführen.

Executor: Führt die Anweisung aus und gibt Daten von der Speicher-Engine zurück.

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

Serverschicht: Enthält hauptsächlich Konnektoren und Abfragen Cache, Analysator, Optimierer, Executor usw., alle speicherübergreifenden Engine-Funktionen wie gespeicherte Prozeduren, Trigger, Ansichten, Funktionen usw. werden in dieser Schicht implementiert. Außerdem gibt es ein allgemeines Protokollmodul, das Binglog-Protokollmodul.

Speicher-Engine: Hauptsächlich für die Datenspeicherung und das Lesen verantwortlich. Sie verwendet eine austauschbare Plug-in-Architektur und unterstützt mehrere Speicher-Engines wie InnoDB, MyISAM und Memory. Darunter auch die InnoDB Die Engine verfügt über ein eigenes Protokollmodul, ein Redolog-Modul. Die derzeit am häufigsten verwendete Speicher-Engine ist InnoDB, die seit MySQL-Version 5.5.5 als Standard-Speicher-Engine verwendet wird.

1.2 Einführung in die Grundkomponenten der Serverschicht

1) Connector

Connectoren beziehen sich hauptsächlich auf Funktionen im Zusammenhang mit Identitätsauthentifizierung und Berechtigungen, genau wie a sehr hohes Niveau Wie der Portier.

ist hauptsächlich für die Benutzeranmeldedatenbank und die Benutzeridentitätsauthentifizierung verantwortlich, einschließlich der Überprüfung von Kontokennwörtern, Berechtigungen und anderen Vorgängen. Wenn das Benutzerkontokennwort bestanden wurde, fragt der Connector alle Berechtigungen des Benutzers in der Berechtigungstabelle ab , und dann Die logische Beurteilung der Berechtigungen in dieser Verbindung basiert auf den zu diesem Zeitpunkt gelesenen Berechtigungsdaten. Mit anderen Worten: Solange die Verbindung nicht getrennt wird, ist der Benutzer nicht betroffen, selbst wenn der Administrator die Berechtigungen ändert .

2) Abfragecache (nach MySQL 8.0-Version entfernt)

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

Nachdem die Verbindung hergestellt wurde, wird beim Ausführen der Abfrageanweisung zunächst der Cache abgefragt, ob die SQL ausgeführt wurde, und sie in Form eines Schlüsselwerts im Speicher zwischenspeichern ist die Abfrageschätzung und Wert ist die Ergebnismenge. Wenn der Cache-Schlüssel getroffen wird, wird er direkt an den Client zurückgegeben. Wenn kein Treffer vorliegt, werden nachfolgende Vorgänge ausgeführt. Nach Abschluss wird das Ergebnis zwischengespeichert, um den nächsten Aufruf zu erleichtern. Wenn die Cache-Abfrage tatsächlich ausgeführt wird, werden natürlich weiterhin die Berechtigungen des Benutzers überprüft, um festzustellen, 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 Abfrage-Cache-Fehlern kommen kann. Wenn Sie eine Tabelle aktualisieren, werden alle Abfrage-Caches in dieser Tabelle geleert. Für Daten, die nicht häufig aktualisiert werden, ist es dennoch möglich, Caching zu verwenden.

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

Die Caching-Funktion wurde nach der MySQL-Version 8.0 gelöscht. Beamte glaubten auch, dass diese Funktion nur wenige praktische Anwendungsszenarien hatte, also löschten sie sie einfach.

3) Analysator

MySQL gelangt nicht in den Cache, sondern in den Analysator. Der Analysator wird hauptsächlich zur Analyse des Zwecks der SQL-Anweisung verwendet Mehrere Kategorien. Schritt:

Der erste Schritt ist die lexikalische Analyse . Zuerst müssen Sie Schlüsselwörter extrahieren, z. B. „Auswählen“, „Vorschlagen der Abfragetabelle“, „Vorschlagen“. Namen, Abfragebedingungen und so weiter. Nach Abschluss dieser Vorgänge gelangen Sie zum zweiten Schritt.

Der zweite Schritt, die Syntaxanalyse, besteht hauptsächlich darin, festzustellen, ob die von Ihnen eingegebene SQL korrekt ist und der Syntax von MySQL entspricht.

Nach Abschluss dieser beiden Schritte ist MySQL bereit, mit der Ausführung zu beginnen. Aber wie führt man sie aus und wie erzielt man das beste Ergebnis? Zu diesem Zeitpunkt muss der Optimierer ins Spiel kommen.

4) Optimierer

Die Funktion des Optimierers besteht darin, den seiner Meinung nach optimalen Ausführungsplan auszuführen (manchmal ist er möglicherweise nicht optimal. Dieser Artikel enthält eine ausführliche Erläuterung dieses Wissens). Zum Beispiel, wie man einen Index auswählt, wenn mehrere Indizes vorhanden sind, wie man die Korrelationsreihenfolge auswählt, wenn man mehrere Tabellen abfragt usw.

Man kann sagen, dass nach Durchlaufen des Optimierers festgestellt werden kann, dass die spezifische Ausführung dieser Anweisung bestimmt wurde.

5) Executor

Nach der Auswahl des Ausführungsplans ist MySQL bereit, die Ausführung zu starten. Zunächst prüft es, ob der Benutzer über die Berechtigung verfügt. Wenn keine Berechtigung vorliegt, wird ein Fehler angezeigt Wenn Informationen zurückgegeben werden, ruft es die Schnittstelle der Engine auf und gibt das Ergebnis der Schnittstellenausführung zurück.

2 Anweisungsanalyse

2.1 Abfrageanweisung

Nach so viel gesagt: Wie wird eine SQL-Anweisung ausgeführt? Tatsächlich kann unser SQL in zwei Typen unterteilt werden: einer ist Abfrage und der andere ist Aktualisierung (Hinzufügen, Aktualisieren, Löschen). Lassen Sie uns zunächst die Abfrageanweisung analysieren:

select * from tb_student  A where A.age='18' and A.name=' 张三 ';

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

Überprüfen Sie zunächst, ob die Anweisung über die Berechtigung If verfügt Es liegt keine Berechtigung vor. Wenn Sie über die Berechtigung verfügen, wird vor der MySQL8.0-Version zuerst der Cache abgefragt und diese SQL-Anweisung als Schlüssel für die Abfrage verwendet, ob ein Ergebnis im Speicher vorhanden ist . Wenn ein direkter Cache vorhanden ist, fahren Sie mit dem nächsten Schritt fort.

Führen Sie eine lexikalische Analyse durch und extrahieren Sie die Schlüsselelemente der SQL-Anweisung. Die obige Anweisung ist beispielsweise eine Abfrage. Der Name der abzufragenden Tabelle lautet tb_student abgefragt. Die Abfragebedingungen sind: Die ID dieser Tabelle ist „1“. Stellen Sie dann fest, ob die SQL-Anweisung Syntaxfehler aufweist, z. B. ob die Schlüsselwörter korrekt sind usw. Wenn kein Problem vorliegt, fahren Sie mit dem nächsten Schritt fort.

Der nächste Schritt besteht darin, dass der Optimierer den Ausführungsplan bestimmt. Die obige SQL-Anweisung kann zwei Ausführungspläne haben:

  a.先查询学生表中姓名为“张三”的学生，然后判断是否年龄是 18。
  b.先找出学生中年龄 18 岁的学生，然后再查询姓名为“张三”的学生。

Dann wählt der Optimierer die Ausführungseffizienz entsprechend seiner eigenen Optimierung aus Algorithmus Die beste Lösung (der Optimierer denkt, dass es manchmal nicht die beste ist). Nachdem Sie den Ausführungsplan bestätigt haben, können Sie mit der Ausführung beginnen.

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

2.2 Update-Anweisung

Das Obige ist der Ausführungsprozess einer SQL-Abfrage. Schauen 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=' 张三 ';

Ändern wir das Alter von Zhang San. Das Altersfeld wird definitiv nicht in der tatsächlichen Datenbank festgelegt, sonst wird es von der verantwortlichen technischen Person übertroffen. Tatsächlich folgt jede Anweisung grundsätzlich dem Prozess der vorherigen Abfrage, das Protokoll muss jedoch beim Ausführen des Updates aufgezeichnet werden. Dadurch wird das Protokollmodul binlog (Archivprotokoll) eingeführt. Alle Speicher-Engines können verwendet werden. Unsere häufig verwendete InnoDB-Engine verfügt auch über ein Protokollmodul Redo-Protokoll (Redo-Protokoll) . Wir werden die Ausführung dieser Anweisung im InnoDB-Modusprozess diskutieren. Der Vorgang ist wie folgt:

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

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

Nach Erhalt der Benachrichtigung zeichnet der Executor das Binlog auf, ruft dann die Engine-Schnittstelle auf und übermittelt das Redo-Protokoll als Übermittlungsstatus.

Update abgeschlossen.

Einige Studenten hier werden sich sicherlich fragen, warum wir zwei Protokollmodule anstelle eines Protokollmoduls verwenden müssen?

Das liegt daran, dass MySQL bei InnoDB nicht funktioniert hat Der Anfang. Engine (Die InnoDB-Engine wird von anderen Unternehmen in Form eines Plug-Ins in MySQL eingefügt.) Wir wissen jedoch, dass das Redo-Protokoll nur für die InnoDB-Engine gilt und in anderen Speicher-Engines nicht verfügbar ist Dies führt dazu, dass keine Absturzsicherung möglich ist (auch bei einem abnormalen Neustart der Datenbank können zuvor übermittelte Datensätze nicht zur Archivierung verwendet werden).

Es ist nicht so, dass Sie nicht nur ein Protokollmodul verwenden können, es ist nur so, dass die InnoDB-Engine Transaktionen über Redo-Log unterstützt. Dann werden einige Studenten fragen: Kann ich zwei Protokollmodule verwenden, aber nicht so kompliziert? Warum führt Redo-Log den Vorbereitungs-Pre-Commit-Status ein? Hier verwenden wir einen Widerspruchsbeweis, um zu erklären, warum wir das tun?

Schreiben Sie zuerst das Redo-Protokoll und senden Sie es direkt, und schreiben Sie dann das Binlog. Angenommen, die Maschine bleibt hängen und das Binlog-Protokoll wird nicht geschrieben Wenn die Maschine neu gestartet wird, werden die Daten über das Redo-Protokoll wiederhergestellt, aber Bingog zeichnet die Daten zu diesem Zeitpunkt nicht auf. Wenn die Maschine später gesichert wird, gehen diese Daten und die Master-Slave-Synchronisation verloren diese Daten verlieren.

Schreiben Sie zuerst das Binlog und dann das Redo-Log Angenommen, der Computer startet nach dem Schreiben des Binlogs nicht normal neu, da kein Redo-Log vorhanden ist. Wenn das Binlog jedoch einen Datensatz enthält, führt derselbe Grund wie oben zu Dateninkonsistenzen.

Wenn die zweistufige Redo-Log-Übermittlungsmethode verwendet wird, ist es anders. Nach dem Schreiben des Binglogs und der anschließenden Übermittlung des Redo-Logs werden die oben genannten Probleme vermieden und die Konsistenz der Daten sichergestellt. Die Frage ist also: Liegt eine Extremsituation vor? Angenommen, das Redo-Protokoll befindet sich im Pre-Commit-Status und das Binglog wurde geschrieben. Was passiert, wenn zu diesem Zeitpunkt ein abnormaler Neustart auftritt?
Dies hängt vom Verarbeitungsmechanismus von MySQL ab:

Beurteilen Sie, ob das Redo-Protokoll vollständig ist, und senden Sie es sofort.

Wenn das Redo-Protokoll nur vorab übermittelt wurde, sich aber nicht im Commit-Status befindet, wird beurteilt, ob das Binlog vollständig ist. Wenn es unvollständig ist, wird die Transaktion übermittelt zurückgerollt.

Dadurch wird das Problem der Datenkonsistenz gelöst.

Drei Zusammenfassung

MySQL ist hauptsächlich in Server- und Engine-Schichten unterteilt. Die Serverschicht umfasst hauptsächlich Konnektoren, Abfrage-Caches, Analysatoren, Optimierer und Executoren Ein Protokollmodul (Binlog), das von allen Ausführungs-Engines gemeinsam genutzt werden kann, ist nur in InnoDB verfügbar.

Die Engine-Schicht ist vom Plug-in-Typ und umfasst derzeit hauptsächlich MyISAM, InnoDB, Speicher usw.

Der Ausführungsprozess der Abfrageanweisung ist wie folgt: Berechtigungsüberprüfung (wenn der Cache erreicht wird) --- „Abfragecache ---“ Analysator --- „Optimierer --- „Berechtigungsüberprüfung --- „Ausführer“. - --》Engine

Der Ausführungsprozess der Update-Anweisung ist wie folgt: Analysegerät----》Berechtigungsüberprüfung----》Executor---》Engine---redo log(prepare status--- 》 binlog---》Redo-Protokoll (Commit-Status) [Verwandte Empfehlungen: MySQL-Tutorial]

Das obige ist der detaillierte Inhalt vonWie werden SQL-Anweisungen in MySQL ausgeführt?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!