Aurora In meinem SQL Thread heißt es

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

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

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.

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.

Die Abfrage konvertiert eine temporäre Tabelle von In-Memory in On-Disk. Diese Konvertierung ist erforderlich, da die temporären Tabellen, die von My SQL in den Zwischenschritten der Abfrageverarbeitung erstellt wurden, zu groß für den Arbeitsspeicher 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.

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

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.

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

Der Thread erstellt eine permanente oder temporäre Tabelle.

Ein asynchroner Commit in Aurora My SQL hat eine Bestätigung erhalten und ist abgeschlossen.

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

Ein Aurora My SQL 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.

Ein Aurora My SQL 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.

Der Thread hat begonnen, eine Anweisung auszuführen.

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.

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.

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.

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.

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

Dieser Status tritt während der Abfrageoptimierung auf.

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

Aurora My SQL konnte einen DISTINCT Vorgang in der Anfangsphase einer Abfrage nicht optimieren. Aurora My SQL muss alle doppelten Zeilen entfernen, bevor das Ergebnis an den Client gesendet wird.

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.

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

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

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.

Der Server schreibt ein Paket an den Client. In früheren SQL Versionen von My wurde dieses Warteereignis mit der Bezeichnung „Warten“ gekennzeichnetwriting to net.

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

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.

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

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.

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

Der Thread sucht nach Zeilen und aktualisiert sie.

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

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.

Dies ist ein Warten auf eine Metadatensperre.

Dies ist ein Warten auf eine Metadatensperre.

Dies ist ein Warten auf eine Metadatensperre.

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.

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

Aurora My SQL verwendet Metadatensperrung, 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.

Der Server schreibt ein Paket in das Netzwerk. In späteren SQL Versionen von My trägt dieses Wartungsereignis die BezeichnungSending to client.