Dieser Artikel stellt Ihnen die MySQL-Architekturkomponenten vor. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.
Der Connector ist hauptsächlich dafür verantwortlich, eine Verbindung mit dem Client herzustellen, Berechtigungen zu überprüfen und die Verbindung zu verwalten. Mit dem Befehl show Processlist können Sie die Verbindungsinformationen anzeigen. Wenn eine Benutzerverbindung erfolgreich erstellt wurde, wurden die Berechtigungsinformationen in den Speicher eingelesen. Wenn die Berechtigungen des Benutzers später geändert werden, werden sie nicht wirksam, wenn sie nicht aktualisiert werden.
Wenn bei einer Verbindung längere Zeit kein Befehl empfangen wird (sie befindet sich im Ruhezustand), trennt der Connector die Verbindung nach einer bestimmten Zeit. Diese Zeit wird durch den Parameter wait_timeout gesteuert, der standardmäßig 8 Stunden beträgt.
Die Verbindungen im Connector sind in lange Verbindungen und kurze Verbindungen unterteilt:
Lange Verbindung: Nach erfolgreicher Verbindung fordert der Client die Verwendung derselben Verbindung an.
Denn in normalen Zeiten verwenden wir normalerweise lange Verbindungen, d. h. die Aufrechterhaltung einer Verbindung für eine lange Zeit, ohne es zu trennen. Es ist jedoch zu beachten, dass eine Verbindung einen Teil des von ihr während der Verwendung belegten Speichers verwaltet und zusammen mit der Verbindung freigegeben wird, wenn die Verbindung getrennt wird. Wenn die Verbindung nicht getrennt wird und sich über einen längeren Zeitraum ohne Verarbeitung ansammelt, kann dies zu einer übermäßigen Speichernutzung führen und vom System zwangsweise beendet werden. Im Allgemeinen gibt es zwei Lösungen:
Trennen Sie lange Verbindungen regelmäßig, trennen Sie die Verbindung nach einer gewissen Zeit oder nach der Ausführung einer Abfrage, die viel Speicher beansprucht, wodurch Speicher freigegeben wird, und stellen Sie die Verbindung neu her, wenn eine Abfrage erforderlich ist
Versionen nach 5.7 können mysql_reset_connection verwenden, um Verbindungsressourcen ohne erneute Verbindung und Berechtigungsüberprüfung neu zu initialisieren und die Verbindung in den Zustand zurückzusetzen, in dem sie erstellt wurde. Gleichzeitig wird es auch einige andere Effekte geben, wie z. B. das Aufheben von Tabellensperren, das Löschen temporärer Tabellen, das Zurücksetzen von in der Sitzung festgelegten Variablen usw.
Hinweis: Der Abfrage-Cache wurde danach abgeschafft Version 8.0
Die Verbindung wurde erfolgreich erstellt. Danach können Sie die SQL-Anweisung ausführen. Wenn der Abfragecache jedoch aktiviert ist, wird die Abfrage aus dem Cache abgefragt, bevor die SQL tatsächlich analysiert wird direkt zurückgegeben werden. Der Abfragecache ist eine Schlüssel-Wert-Struktur, wobei Key die SQL-Anweisung und Value das entsprechende Abfrageergebnis ist. Wenn der Cache fehlt, werden nachfolgende Abfragevorgänge fortgesetzt. Nachdem die Abfrage abgeschlossen ist, werden die Ergebnisse im Abfragecache gespeichert.
Warum wird der Abfragecache gelöscht? Weil Abfrage-Caching in der Regel mehr schadet als nützt. Wenn eine Tabelle aktualisiert wird, wird der der Tabelle entsprechende Abfragecache geleert. Bei Tabellen, die häufig aktualisiert werden, wird der Abfragecache sehr häufig ungültig und funktioniert grundsätzlich nicht. Außerdem entsteht ein Mehraufwand für die Aktualisierung des Caches. Für Datentabellen, die grundsätzlich unverändert bleiben, können Sie sich für die Verwendung von Abfrage-Caching entscheiden, z. B. für Systemkonfigurationstabellen. Die Cache-Trefferquote solcher Tabellen ist höher und die Vorteile können die Nachteile überwiegen Verwenden Sie auch externes Caching.
Sie können den Abfragecache über den Parameter query_cache_type konfigurieren. Dieser Parameter hat drei optionale Werte:
0: Abfragecache ausschalten
1: Abfragecache einschalten
2 : Wenn vorhanden, verwenden Sie den Abfragecache, wenn Sie das Schlüsselwort SQL_CACHE verwenden, z. B. select SQL_CACHE * from t where xxx; und die SQL muss vor der Ausführung analysiert werden. Diese Analyse ist hauptsächlich in zwei Schritte unterteilt: lexikalische Analyse und Syntaxanalyse.
Die logische Konvertierung ähnelt der statischen Kompilierzeitoptimierung von Java, die SQL „vereinfacht“, um konsistente Ausführungsergebnisse vor und nach der SQL-Konvertierung sicherzustellen. Beispielsweise kann 1=1 und a.id = 2 äquivalent zu a.id = 2 sein.
Der Optimierer berechnet die endgültigen Kosten eines Abfrageplans basierend auf dem generierten Abfrageplan und den beiden oben genannten Kostenkonfigurationen und wählt aus mehreren Abfrageplänen denjenigen mit den geringsten Kosten aus, der dem Ausführenden zur Ausführung vorgelegt wird. Allerdings ist zu beachten, dass die geringsten Kosten manchmal nicht unbedingt die kürzeste Ausführungszeit bedeuten.
Der Executor führt SQL gemäß dem vom Optimierer ausgewählten Abfrageplan aus. Vor der Ausführung überprüft er außerdem, ob der anfordernde Benutzer über die entsprechenden Abfrageberechtigungen verfügt, und ruft schließlich die von der MySQL-Engine-Schicht bereitgestellte Schnittstelle auf um die SQL-Anweisung auszuführen und Ergebnisse zurückzugeben. Wenn das Abfrage-Caching aktiviert ist, werden die Ergebnisse auch im Abfrage-Cache gespeichert.
Verwandte Empfehlungen: „MySQL-Tutorial“
Das obige ist der detaillierte Inhalt vonWas sind MySQL-Architekturkomponenten?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!