Aurora-MySQL-Thread-Zustände

Im Folgenden werden einige allgemeine Thread-Zustände für Aurora MySQL aufgeführt.

Berechtigungen werden überprüft

Der Thread prüft, ob der Server über die erforderlichen Berechtigungen zum Ausführen der Anweisung verfügt.

Abfrage-Cache auf Abfrage prüfen

Der Server prüft, ob die aktuelle Abfrage im Abfrage-Cache vorhanden ist.

Bereinigen

Dies ist der endgültige Status einer Verbindung, deren Arbeit abgeschlossen ist, aber vom Client nicht geschlossen wurde. Die beste Lösung besteht darin, die Verbindung explizit im Code zu schließen. Oder Sie stellen einen niedrigeren Wert für wait_timeout in Ihrer Parametergruppe ein.

Schließen von Tabellen

Der Thread löscht die geänderten Tabellendaten auf die Festplatte und schließt die verwendeten Tabellen. Wenn dies kein schneller Vorgang ist, überprüfen Sie die Metriken für den Verbrauch der Netzwerkbandbreite im Hinblick auf die Netzwerkbandbreite der Instance-Klasse. Überprüfen Sie außerdem, ob die Parameterwerte für die Parameter table_open_cache und table_definition_cache erlauben, dass genügend Tabellen gleichzeitig geöffnet sind, damit die Engine Tabellen nicht häufig öffnen und schließen muss. Diese Parameter beeinflussen den Speicherverbrauch der Instance.

Konvertieren von HEAP in myISAM

Die Abfrage konvertiert eine temporäre Tabelle von In-Memory in On-Disk. Diese Konvertierung ist notwendig, da die von MySQL in den Zwischenschritten der Abfrageverarbeitung erstellten temporären Tabellen für den Speicher zu groß wurden. Überprüfen Sie die Werte von tmp_table_size und max_heap_table_size. In späteren Versionen lautet dieser Threadstatusname converting HEAP to ondisk.

Konvertieren von HEAP in Ondisk

Der Thread konvertiert eine interne temporäre Tabelle von einer In-Memory-Tabelle in eine On-Disk-Tabelle.

in tmp-Tabelle kopieren

Der Thread verarbeitet eine ALTER TABLE-Anweisung. Dieser Status tritt auf, nachdem die Tabelle mit der neuen Struktur erstellt wurde, aber bevor Zeilen in sie kopiert werden. Für einen Thread in diesem Status können Sie das Leistungsschema verwenden, um Informationen über den Fortschritt des Kopiervorgangs zu erhalten.

Sortierindex erstellen

Aurora MySQL führt eine Sortierung durch, weil es keinen vorhandenen Index verwenden kann, um die ORDER BY- oder GROUP BY-Klausel einer Abfrage zu erfüllen. Weitere Informationen finden Sie unter Erstellen des Sortierindex.

Tabelle wird erstellt

Der Thread erstellt eine permanente oder temporäre Tabelle.

verzögertes Commit ok fertig

Ein asynchrones Commit in Aurora MySQL hat eine Bestätigung erhalten und ist vollständig.

verzögertes Commit ok initiiert

Der Aurora MySQL-Thread hat den asynchronen Commit-Prozess gestartet, wartet aber auf die Bestätigung. Dies ist normalerweise die echte Commit-Zeit einer Transaktion.

verzögert senden ok fertig

Ein Aurora MySQL-Worker-Thread, der an eine Verbindung gebunden ist, kann freigegeben werden, während eine Antwort an den Client gesendet wird. Der Thread kann mit anderen Arbeiten beginnen. Der Zustand delayed send ok bedeutet, dass die asynchrone Quittung an den Client abgeschlossen ist.

verzögert senden ok initiiert

Ein Aurora MySQL-Worker-Thread hat asynchron eine Antwort an einen Client gesendet und kann nun für andere Verbindungen arbeiten. Die Transaktion hat einen asynchronen Commit-Prozess gestartet, der noch nicht bestätigt wurde.

executing

Der Thread hat begonnen, eine Anweisung auszuführen.

Freigeben von Gegenständen

Der Thread hat einen Befehl ausgeführt. Ein gewisses Freigeben von Elementen, die in diesem Status durchgeführt wurden, beinhaltet den Abfrage-Cache. Auf diesen Zustand folgt normalerweise ein Aufräumen.

init

Dieser Zustand tritt vor der Initialisierung von ALTER TABLE-, DELETE-, INSERT-, SELECT- oder UPDATE-Anweisungen auf. Zu den Aktionen in diesem Status gehören das Löschen des Binärprotokolls oder des InnoDB-Protokolls und eine Bereinigung des Abfrage-Caches.

master hat alle Binlog an Slave geschickt

Der Primärknoten hat seinen Teil der Replikation abgeschlossen. Der Thread wartet darauf, dass weitere Abfragen ausgeführt werden, damit er in das Binärprotokoll (Binlog) schreiben kann.

Öffnen von Tabellen

Der Thread versucht eine Tabelle zu öffnen. Dieser Vorgang ist schnell, es sei denn, eine ALTER TABLE- oder LOCK TABLE-Anweisung muss beendet werden oder sie überschreitet den Wert von table_open_cache.

optimieren

Der Server führt erste Optimierungen für eine Abfrage durch.

vorbereiten

Dieser Status tritt während der Abfrageoptimierung auf.

Abfrage Ende

Dieser Status tritt nach der Verarbeitung einer Abfrage jedoch vor dem Status „Freigegebene Elemente“ auf.

Entfernen von Duplikaten

Aurora MySQL konnte einen DISTINCT-Vorgang in der frühen Phase einer Abfrage nicht optimieren. Aurora MySQL muss alle duplizierten Zeilen entfernen, bevor das Ergebnis an den Client gesendet wird.

Zeilen nach Update suchen

Der Thread findet alle übereinstimmenden Zeilen, bevor er sie aktualisiert. Diese Phase ist erforderlich, wenn UPDATE den Index ändert, den die Engine zum Auffinden der Zeilen verwendet.

Binlog-Ereignis an Slave senden

Der Thread liest ein Ereignis aus dem Binärprotokoll und sendet es an das Replikat.

Zwischengespeichertes Ergebnis an den Client senden

Der Server nimmt das Ergebnis einer Abfrage aus dem Abfrage-Cache und sendet es an den Client.

senden von Daten

Der Thread liest und verarbeitet Zeilen für eine SELECT-Anweisung, hat aber noch nicht damit begonnen, Daten an den Client zu senden. Der Prozess identifiziert, welche Seiten die Ergebnisse enthalten, die erforderlich sind, um die Abfrage zu erfüllen. Weitere Informationen finden Sie unter Senden von Daten.

an den Kunden senden

Der Server schreibt ein Paket an den Client. In früheren MySQL-Versionen wurde dieses Warteereignis mit writing to net bezeichnet.

starting

Dies ist die erste Stufe zu Beginn der Ausführung von Anweisungen.

statistics

Der Server berechnet Statistiken, um einen Abfrageausführungsplan zu entwickeln. Wenn sich ein Thread längere Zeit in diesem Zustand befindet, ist der Server wahrscheinlich festplattengebunden, während er andere Arbeiten ausführt.

Speichern von Ergebnis im Abfrage-Cache

Der Server speichert das Ergebnis einer Abfrage im Abfrage-Cache.

Systemsperre

Der Thread hat mysql_lock_tables aufgerufen, aber der Threadstatus wurde seit dem Aufruf nicht aktualisiert. Dieser allgemeine Zustand tritt aus vielen Gründen auf.

update

Der Thread bereitet sich darauf vor, die Tabelle zu aktualisieren.

executing

Der Thread sucht nach Zeilen und aktualisiert sie.

Benutzersperre

Der Thread hat einen GET_LOCK-Aufruf ausgegeben. Der Thread hat entweder eine Beratungssperre angefordert und wartet darauf oder plant, sie anzufordern.

auf weitere Updates warten

Der Primärknoten hat seinen Teil der Replikation abgeschlossen. Der Thread wartet darauf, dass weitere Abfragen ausgeführt werden, damit er in das Binärprotokoll (Binlog) schreiben kann.

Warten auf Schema-Metadatensperre

Dies ist ein Warten auf eine Metadatensperre.

auf die Sperre der gespeicherten Funktion Metadaten

Dies ist ein Warten auf eine Metadatensperre.

Warten auf Metadatensperre der gespeicherten

Dies ist ein Warten auf eine Metadatensperre.

Warten auf Tabellenintegration

Der Thread führt FLUSH TABLES aus und wartet darauf, dass alle Threads ihre Tabellen schließen. Oder der Thread erhielt eine Benachrichtigung, dass sich die zugrunde liegende Struktur für eine Tabelle geändert hat, daher muss er die Tabelle erneut öffnen, um die neue Struktur zu erhalten. Um die Tabelle erneut zu öffnen, muss der Thread warten, bis alle anderen Threads die Tabelle geschlossen haben. Diese Benachrichtigung erfolgt, wenn ein anderer Thread eine der folgenden Anweisungen in der Tabelle verwendet hat: FLUSH TABLES, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, oder OPTIMIZE TABLE.

auf Tabellen-Levelsperre

Eine Sitzung hält eine Sperre für eine Tabelle, während eine andere Sitzung versucht, dieselbe Sperre für dieselbe Tabelle zu erwerben.

Warten auf Tabellen-Metadatensperre

Aurora MySQL verwendet die Sperre von Metadaten, um den gleichzeitigen Zugriff auf Datenbankobjekte zu verwalten und die Datenkonsistenz sicherzustellen. In diesem Warteereignis hält eine Sitzung eine Metadatensperre für eine Tabelle, während eine andere Sitzung versucht, dieselbe Sperre für dieselbe Tabelle zu erwerben. Wenn das Leistungsschema aktiviert ist, wird dieser Threadstatus als Warteereignis synch/cond/sql/MDL_context::COND_wait_status gemeldet.

Schreiben ins Netz

Der Server schreibt ein Paket in das Netzwerk. In späteren MySQL-Versionen wird dieses Warteereignis mit Sending to client markiert.