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.

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:

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 im MySQL-Referenzhandbuch.

Wenn Sie Performance Insights verwenden, gilt eine der folgenden Bedingungen:

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 Überblick über das Leistungsschema für Performance Insights auf Aurora My SQL My SQL.

Aurora-MySQL-Speicher

In Aurora MySQL sind die wichtigsten Speicherbereiche der Pufferpool und der Protokollpuffer.

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 im MySQL-Referenzhandbuch.

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.