Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Grundlegende Konzepte für Aurora-MySQL-Optimierung
Bevor Sie Ihre Aurora-MySQL-Datenbank optimieren, stellen Sie sicher, dass Sie wissen, was Warteereignisse und Thread-Zustände sind und warum sie auftreten. Überprüfen Sie auch die grundlegende Speicher- und Festplattenarchitektur von Aurora MySQL, wenn Sie die InnoDB-Speicher-Engine verwenden. Ein hilfreiches Architekturdiagramm finden Sie im MySQL-Referenzhandbuch
Themen
Aurora-MySQL-Warteereignisse
Ein Warteereignis zeigt eine Ressource an, auf die eine Sitzung wartet. Das Warteereignis io/socket/sql/client_connection zeigt beispielsweise an, dass ein Thread gerade eine neue Verbindung verarbeitet. Zu den typischen Ressourcen, auf die eine Sitzung wartet, gehören die folgenden:
-
Singlethread-Zugriff auf einen Puffer, beispielsweise wenn eine Sitzung versucht, einen Puffer zu ändern
-
Eine Zeile, die derzeit von einer anderen Sitzung gesperrt ist
-
Eine gelesene Datendatei
-
Eine geschriebene Protokolldatei
Um beispielsweise eine Abfrage zu erfüllen, kann die Sitzung einen vollständigen Tabellenscan durchführen. Wenn sich die Daten noch nicht im Arbeitsspeicher befinden, wartet die Sitzung, bis die Datenträger-I/O abgeschlossen ist. Wenn die Puffer in den Speicher gelesen werden, muss die Sitzung möglicherweise warten, da andere Sitzungen auf dieselben Puffer zugreifen. Die Datenbank zeichnet die Wartezeiten unter Verwendung eines vordefinierten Warteereignisses auf. Diese Ereignisse sind in Kategorien eingeteilt.
Ein Wait-Ereignis allein zeigt kein Leistungsproblem an. Wenn sich beispielsweise die angeforderten Daten nicht im Speicher befinden, müssen die Daten von der Festplatte gelesen werden. Wenn eine Sitzung eine Zeile für eine Aktualisierung sperrt, wartet eine andere Sitzung darauf, dass die Zeile entsperrt wird, damit sie sie aktualisieren kann. Bei einem Commit muss gewartet werden, bis der Schreibvorgang in eine Protokolldatei abgeschlossen ist. Wartezeiten sind ein wesentlicher Bestandteil des normalen Funktionierens einer Datenbank.
Eine große Anzahl von Warteereignissen weist normalerweise auf ein Leistungsproblem hin. In solchen Fällen können Sie Warteereignisdaten verwenden, um zu bestimmen, wo die Sitzungen Zeit verbringen. Wenn beispielsweise ein Bericht, der normalerweise in Minuten ausgeführt wird, jetzt stundenlang ausgeführt wird, können Sie die Warteereignisse identifizieren, die am meisten zur Gesamtwartezeit beitragen. Wenn Sie die Ursachen für die häufigsten Warteereignisse ermitteln können, können Sie manchmal Änderungen vornehmen, die die Leistung verbessern. Wenn Ihre Sitzung beispielsweise auf eine Zeile wartet, die von einer anderen Sitzung gesperrt wurde, können Sie die Sperrsitzung beenden.
Aurora-MySQL-Thread-Zustände
Ein allgemeiner Thread-Zustand ist ein State-Wert, der der allgemeinen Abfrageverarbeitung zugeordnet ist. Der Thread-Zustand sending data gibt beispielsweise an, dass ein Thread Zeilen für eine Abfrage liest und filtert, um die richtige Ergebnismenge zu ermitteln.
Sie können Thread-Zustände verwenden, um Aurora MySQL auf ähnliche Weise zu optimieren, wie Sie Warteereignisse verwenden. Häufiges Vorkommen von sending data weist beispielsweise normalerweise darauf hin, dass eine Abfrage keinen Index verwendet. Weitere Informationen zu Thread-Zuständen finden Sie unter Allgemeine Thread-Zustände
Wenn Sie Performance Insights verwenden, gilt eine der folgenden Bedingungen:
-
Performance Schema ist aktiviert – Aurora MySQL zeigt Warteereignisse anstelle des Thread-Zustands an.
-
Performance-Schema ist nicht aktiviert – Aurora MySQL zeigt den Thread-Zustand an.
Es wird empfohlen, Performance Schema für die automatische Verwaltung zu konfigurieren. Das Leistungsschema bietet zusätzliche Einblicke und bessere Tools zur Untersuchung potenzieller Leistungsprobleme. Weitere Informationen finden Sie unter Aktivieren des Leistungsschemas für Performance Insights in Aurora MySQL.
Aurora-MySQL-Speicher
In Aurora MySQL sind die wichtigsten Speicherbereiche der Pufferpool und der Protokollpuffer.
Themen
Puffer Pool
Der Pufferpool ist der gemeinsam genutzte Speicherbereich, in dem Aurora MySQL Tabellen- und Indexdaten zwischenspeichert. Abfragen können direkt aus dem Speicher auf häufig verwendete Daten zugreifen, ohne von der Festplatte zu lesen.
Der Pufferpool ist als verknüpfte Seitenliste strukturiert. Eine Seite kann mehrere Zeilen enthalten. Aurora MySQL verwendet einen LRU-Algorithmus (Least Latest Used), um Seiten aus dem Pool zu altern.
Weitere Informationen finden Sie unter Pufferpool
Aurora-MySQL-Prozesse
Aurora MySQL verwendet ein Prozessmodell, das sich stark von Aurora PostgreSQL unterscheidet.
MySQL-Server (mysqld)
Der MySQL-Server ist ein einziger Betriebssystemprozess namens mysqld. Der MySQL-Server erzeugt keine zusätzlichen Prozesse. Daher verwendet eine Aurora-MySQL-Datenbank mysqld, um den größten Teil ihrer Arbeit zu erledigen.
Wenn der MySQL-Server startet, lauscht er auf Netzwerkverbindungen von MySQL-Clients. Wenn ein Client eine Verbindung zur Datenbank herstellt, öffnet mysqld einen Thread.
Threads
Verbindungsmanager-Threads verknüpfen jede Clientverbindung mit einem dedizierten Thread. Dieser Thread verwaltet die Authentifizierung, führt Anweisungen aus und gibt Ergebnisse an den Client zurück. Der Verbindungsmanager erstellt bei Bedarf neue Threads.
Der Thread-Cache ist die Menge der verfügbaren Threads. Wenn eine Verbindung endet, gibt MySQL den Thread an den Thread-Cache zurück, wenn der Cache nicht voll ist. Die thread_cache_size-Systemvariable bestimmt die Thread-Cache-Größe.
Thread-Pool
Der Thread-Pool besteht aus einer Reihe von Thread-Gruppen. Jede Gruppe verwaltet eine Reihe von Clientverbindungen. Wenn ein Client eine Verbindung mit der Datenbank herstellt, weist der Thread-Pool die Verbindungen Thread-Gruppen auf Round-Robin-Art zu. Der Thread-Pool trennt Verbindungen und Threads. Es gibt keine feste Beziehung zwischen Verbindungen und den Threads, die Anweisungen ausführen, die von diesen Verbindungen empfangen wurden.
