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.
# Optimieren von Aurora MySQL
Warteereignisse und Thread-Zustände sind wichtige Optimierungs-Tools für Aurora MySQL. Wenn Sie herausfinden, warum Sitzungen auf Ressourcen warten und was sie tun, können Sie Engpässe besser reduzieren. Anhand der Informationen in diesem Abschnitt können Sie mögliche Ursachen und Abhilfemaßnahmen ermitteln.
Amazon DevOps Guru für RDS kann proaktiv feststellen, ob in Ihren Aurora-MySQL-Datenbanken problematische Bedingungen vorliegen, die später zu größeren Problemen führen könnten. Amazon DevOps Guru für RDS veröffentlicht eine Erklärung und Empfehlungen für Korrekturmaßnahmen in einem proaktiven Einblick. Dieser Abschnitt enthält Einblicke in Bezug auf häufig auftretende Probleme.
**Wichtig**
Die Warteereignisse und Thread-Zustände in diesem Abschnitt sind spezifisch für Aurora MySQL. Verwenden Sie die Informationen in diesem Abschnitt, um nur Amazon Aurora zu optimieren, nicht Amazon RDS for MySQL.
Einige Warteereignisse in diesem Abschnitt haben keine Entsprechungen in den Open-Source-Versionen dieser Datenbank-Engines. Andere Warteereignisse haben dieselben Namen wie Ereignisse in Open-Source-Engines, verhalten sich jedoch anders. Beispielsweise funktioniert Amazon-Aurora-Speicher anders als Open-Source-Speicher, sodass speicherbezogene Warteereignisse auf unterschiedliche Ressourcenbedingungen hinweisen.
**Topics**
+ [Grundlegende Konzepte für Aurora-MySQL-Optimierung](AuroraMySQL.Managing.Tuning.concepts.md)
+ [Optimieren von Aurora MySQL mit Warteereignissen](AuroraMySQL.Managing.Tuning.wait-events.md)
+ [Optimierung von Aurora MySQL mit Thread-Status](AuroraMySQL.Managing.Tuning.thread-states.md)
+ [Optimierung von Aurora MySQL mit proaktiven Einblicken von Amazon DevOps Guru](MySQL.Tuning.proactive-insights.md)
# 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](https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html).
**Topics**
+ [Aurora-MySQL-Warteereignisse](#AuroraMySQL.Managing.Tuning.concepts.waits)
+ [Aurora-MySQL-Thread-Zustände](#AuroraMySQL.Managing.Tuning.concepts.thread-states)
+ [Aurora-MySQL-Speicher](#AuroraMySQL.Managing.Tuning.concepts.memory)
+ [Aurora-MySQL-Prozesse](#AuroraMySQL.Managing.Tuning.concepts.processes)
## 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](https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html) im *MySQL-Referenzhandbuch*.
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 [Übersicht über das Leistungsschema für Performance Insights auf Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
## Aurora-MySQL-Speicher
In Aurora MySQL sind die wichtigsten Speicherbereiche der Pufferpool und der Protokollpuffer.
**Topics**
+ [Puffer Pool](#AuroraMySQL.Managing.Tuning.concepts.memory.buffer-pool)
### 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](https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html) im *MySQL-Referenzhandbuch*.
## Aurora-MySQL-Prozesse
Aurora MySQL verwendet ein Prozessmodell, das sich stark von Aurora PostgreSQL unterscheidet.
**Topics**
+ [MySQL-Server (mysqld)](#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld)
+ [Threads](#AuroraMySQL.Managing.Tuning.concepts.processes.threads)
+ [Thread-Pool](#AuroraMySQL.Managing.Tuning.concepts.processes.pool)
### 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.
# Optimieren von Aurora MySQL mit Warteereignissen
Die folgende Tabelle fasst die Aurora-MySQL-Warteereignisse zusammen, die am häufigsten auf Leistungsprobleme hinweisen. Die folgenden Warteereignisse sind eine Teilmenge der Liste in [Aurora-MySQL-Warteereignisse](AuroraMySQL.Reference.Waitevents.md).
| Warteereignis | Description |
| --- | --- |
| [cpu](ams-waits.cpu.md) | Dieses Ereignis tritt auf, wenn ein Thread in der CPU aktiv ist oder auf die CPU wartet. |
| [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) | Dieses Ereignis tritt ein, wenn eine Sitzung persistente Daten in den Aurora-Speicher schreibt. |
| [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) | Das Ereignis tritt auf, wenn ein Thread darauf wartet, eine Ergebnismenge an einen Client zurückzugeben. |
| [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) | Dieses Ereignis tritt ein, wenn eine Sitzung persistente Daten in den Aurora-Speicher schreibt. |
| [io/socket/sql/client\$1verbindung](ams-waits.client-connection.md) | Dieses Ereignis tritt auf, wenn ein Thread gerade eine neue Verbindung verarbeitet. |
| [io/table/sql/handler](ams-waits.waitio.md) | Dieses Ereignis tritt ein, wenn Arbeit an eine Speicher-Engine delegiert wurde. |
| [synch/cond/innodb/row\$1sperren\$1warten](ams-waits.row-lock-wait.md) | Dieses Ereignis tritt auf, wenn eine Sitzung eine Zeile für eine Aktualisierung gesperrt hat und eine andere Sitzung versucht, dieselbe Zeile zu aktualisieren. |
| [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md) | Dieses Ereignis tritt auf, wenn eine Sitzung eine Zeile für eine Aktualisierung gesperrt hat und eine andere Sitzung versucht, dieselbe Zeile zu aktualisieren. |
| [synch/cond/sql/MDL\$1context: :cond\$1wait\$1status](ams-waits.cond-wait-status.md) | Dieses Ereignis tritt ein, wenn Threads auf eine Tabellenmetadatensperre warten. |
| [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) | Dieses Ereignis tritt auf, wenn eine Sitzung eine Zeile für eine Aktualisierung gesperrt hat und eine andere Sitzung versucht, dieselbe Zeile zu aktualisieren. |
| [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md) | Dieses Ereignis tritt ein, wenn ein Thread eine Sperre des InnoDB-Puffer-Pools für den Zugriff auf eine Seite im Speicher erworben hat. |
| [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md) | Dieses Ereignis tritt auf, wenn eine Sitzung darauf wartet, auf den Tablespace-Speichercache zuzugreifen. |
| [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md) | Dieses Ereignis tritt auf, wenn eine hohe Datenbankaktivität mit einer großen Anzahl von Transaktionen besteht. |
| [synch/sxlock/innodb/hash\$1table\$1locks](ams-waits.sx-lock-hash-table-locks.md) | Dieses Ereignis tritt ein, wenn Seiten, die nicht im Pufferpool gefunden wurden, aus einer Datei gelesen werden müssen. |
| [synch/mutex/innodb/temp\$1poolmanager\$1mutex](ams-waits.io-temppoolmanager.md) | Dieses Ereignis tritt auf, wenn eine Sitzung darauf wartet, einen Mutex für die Verwaltung des Pools temporärer Sitzungs-Tablespaces zu erhalten. |
# cpu
Das `cpu`-Warteereignis tritt auf, wenn ein Thread in der CPU aktiv ist oder auf die CPU wartet.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.cpu.context.supported)
+ [Kontext](#ams-waits.cpu.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.cpu.causes)
+ [Aktionen](#ams-waits.cpu.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Versionen 2 und 3
## Kontext
Für jede vCPU kann eine Verbindung an dieser CPU arbeiten. In einigen Situationen ist die Anzahl der aktiven Verbindungen, die betriebsbereit sind, höher als die Anzahl von CPUs v. Dieses Ungleichgewicht führt dazu, dass Verbindungen auf CPU-Ressourcen warten. Wenn die Anzahl der aktiven Verbindungen konstant höher als die Anzahl von v bleibtCPUs, kommt es in Ihrer Instance zu einem CPU-Konflikt. Der Konflikt bewirkt, dass das `cpu`-Warteereignis auftritt.
**Anmerkung**
Die Performance-Insights-Metrik für CPU ist `DBLoadCPU`. Der Wert für `DBLoadCPU` kann sich vom Wert für die CloudWatch Metrik `CPUUtilization` unterscheiden. Die letztere Metrik wird aus der HyperVisor für eine Datenbank-Instance erfasst.
Performance-Insights-OS-Metriken liefern detaillierte Informationen zur CPU-Auslastung. Sie können beispielsweise die folgenden Metriken anzeigen:
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Performance Insights meldet die CPU-Auslastung durch die Datenbank-Engine als `os.cpuUtilization.nice.avg`.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
+ Analytische Abfragen
+ Hochgradig gleichzeitige Transaktionen
+ Langlebige Transaktionen
+ Ein plötzlicher Anstieg der Anzahl von Verbindungen, bekannt als *Login-Sturm*
+ Eine Zunahme des Kontextwechsels
## Aktionen
Wenn das `cpu`-Wait-Ereignis die Datenbankaktivität dominiert, weist dies nicht unbedingt auf ein Leistungsproblem hin. Reagieren Sie auf dieses Ereignis nur, wenn sich die Leistung verschlechtert.
Berücksichtigen Sie je nach Ursache des Anstiegs der CPU-Auslastung die folgenden Strategien:
+ Erhöht die CPU-Kapazität des Hosts. Dieser Ansatz bietet normalerweise nur vorübergehende Erleichterung.
+ Identifizieren Sie Top-Abfragen zur möglichen Optimierung.
+ Leiten Sie ggf. einen schreibgeschützten Workload auf Reader-Knoten um.
**Topics**
+ [Identifizieren Sie die Sitzungen oder Abfragen, die das Problem verursachen](#ams-waits.cpu.actions.az-vpc-subnet)
+ [Analysieren und optimieren Sie die hohe CPU-Workload](#ams-waits.cpu.actions.db-instance-class)
### Identifizieren Sie die Sitzungen oder Abfragen, die das Problem verursachen
Um die Sitzungen und Abfragen zu finden, suchen Sie in der **Top-SQL**-Tabelle in Performance Insights nach den SQL-Anweisungen mit der höchsten CPU-Auslastung. Weitere Informationen finden Sie unter [Analyse der Metriken mit dem Performance-Insights-Dashboard](USER_PerfInsights.UsingDashboard.md).
In der Regel verbrauchen ein oder zwei SQL-Anweisungen den Großteil der CPU-Zyklen. Konzentrieren Sie sich auf diese Anweisungen. Angenommen, Ihre DB-Instance hat 2 V CPUs mit einer Datenbanklast von 3,1 durchschnittlichen aktiven Sitzungen (AAS), die sich alle im CPU-Status befinden. In diesem Fall ist Ihre Instance CPU-gebunden. Berücksichtigen Sie dabei die folgenden Strategien:
+ Führen Sie ein Upgrade auf eine größere Instance-Klasse mit mehr v durchCPUs.
+ Stimmen Sie Ihre Abfragen auf eine geringere CPU-Last ein.
In diesem Beispiel haben die obersten SQL-Abfragen eine DB-Last von 1,5 AAS, alle im CPU-Status. Eine andere SQL-Anweisung hat eine Last von 0,1 im CPU-Status. Wenn Sie in diesem Beispiel die SQL-Anweisung mit der niedrigsten Last gestoppt haben, reduzieren Sie die Datenbanklast nicht wesentlich. Optimieren Sie jedoch die beiden Abfragen mit hoher Last, um doppelt so effizient zu sein, beseitigen Sie den CPU-Engpass. Wenn Sie die CPU-Last von 1,5 AAS um 50 Prozent reduzieren, verringert sich der AAS für jede Anweisung auf 0,75. Die gesamte für die CPU aufgewendete DB-Last beträgt jetzt 1,6 AAS. Dieser Wert liegt unter der maximalen vCPU-Linie von 2,0.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag [Analysieren Sie Amazon Aurora MySQL Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/). Lesen Sie auch den AWS Support-Artikel [Wie kann ich Probleme mit hoher CPU-Auslastung auf meinen Amazon RDS for MySQL MySQL-Instances beheben und beheben?](https://aws.amazon.com/premiumsupport/knowledge-center/rds-instance-high-cpu/) .
### Analysieren und optimieren Sie die hohe CPU-Workload
Nachdem Sie die Abfrage oder Abfragen identifiziert haben, die die CPU-Auslastung erhöhen, können Sie sie entweder optimieren oder die Verbindung beenden. Das folgende Beispiel zeigt, wie Sie eine Verbindung beenden.
```
CALL mysql.rds_kill(processID);
```
Weitere Informationen finden Sie unter [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
Wenn Sie eine Sitzung beenden, löst die Aktion möglicherweise einen langen Rollback aus.
#### Befolgen Sie die Richtlinien für die Optimierung von Abfragen
Beachten Sie die folgenden Richtlinien, um Abfragen zu optimieren:
+ Ausführen der `EXPLAIN`-Anweisung.
Dieser Befehl zeigt die einzelnen Schritte an, die beim Ausführen einer Abfrage beteiligt sind. Weitere Informationen finden Sie unter [Optimierung von Abfragen mit EXPLAIN](https://dev.mysql.com/doc/refman/5.7/en/using-explain.html) in der MySQL-Dokumentation.
+ Ausführen der `SHOW PROFILE`-Anweisung.
Verwenden Sie diese Anweisung, um Profildetails zu überprüfen, die die Ressourcennutzung für Anweisungen angeben können, die während der aktuellen Sitzung ausgeführt werden. Weitere Informationen finden Sie unter [SHOW PROFILE-Anweisung](https://dev.mysql.com/doc/refman/5.7/en/show-profile.html) in der MySQL-Dokumentation.
+ Ausführen der `ANALYZE TABLE`-Anweisung.
Verwenden Sie diese Anweisung, um die Indexstatistiken für die Tabellen zu aktualisieren, auf die die Abfrage mit hohem CPU-Verbrauch zugegriffen wird. Durch die Analyse der Anweisung können Sie dem Optimierer bei der Auswahl eines geeigneten Ausführungsplans helfen. Weitere Informationen finden Sie unter [ANALYZE TABLE](https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html) in der MySQL-Dokumentation.
#### Befolgen Sie die Richtlinien zur Verbesserung der CPU-Auslastung
Um die CPU-Auslastung in einer Datenbank-Instance zu verbessern, befolgen Sie die folgenden Richtlinien:
+ Stellen Sie sicher, dass alle Abfragen die richtigen Indizes verwenden.
+ Finden Sie heraus, ob Sie parallele Aurora-Abfragen verwenden können. Sie können diese Technik verwenden, um die CPU-Auslastung auf dem Hauptknoten zu reduzieren, indem Sie die Funktionsverarbeitung, die Zeilenfilterung und die Spaltenprojektion für die `WHERE`-Klausel herabstufen.
+ Finden Sie heraus, ob die Anzahl der SQL-Ausführungen pro Sekunde die erwarteten Schwellenwerte erfüllt.
+ Finden Sie heraus, ob Indexwartung oder neue Indexerstellung CPU-Zyklen in Anspruch nehmen, die von Ihrer Produktions-Workload benötigt werden Planen Sie Wartungsaktivitäten außerhalb der Spitzenzeiten.
+ Finden Sie heraus, ob Sie die Partitionierung verwenden können, um den Abfragedatensatz zu reduzieren. Weitere Informationen finden Sie im Blogbeitrag [So planen und optimieren Sie Amazon Aurora mit MySQL-Kompatibilität für konsolidierte Workloads](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/).
#### Auf Verbindungsströme überprüfen
Ist die `DBLoadCPU`-Metrik nicht sehr hoch, aber die `CPUUtilization`-Metrik hoch, liegt die Ursache für die hohe CPU-Auslastung außerhalb der Datenbank-Engine. Ein klassisches Beispiel ist ein Verbindungssturm.
Prüfen Sie, ob die folgenden Bedingungen zutreffen:
+ Sowohl bei der Performance Insights `CPUUtilization` Insights-Metrik als auch bei der CloudWatch `DatabaseConnections` Amazon-Metrik ist ein Anstieg zu verzeichnen.
+ Die Anzahl der Threads in der CPU ist größer als die Anzahl von CPUs v.
Wenn die vorhergehenden Bedingungen zutreffen, sollten Sie erwägen, die Anzahl der Datenbankverbindungen zu verringern. Sie können beispielsweise einen Verbindungspool wie RDS-Proxy verwenden. Informationen zu den bewährten Methoden für eine effektive Verbindungsverwaltung und -skalierung finden Sie im Whitepaper [Handbuch von Amazon Aurora MySQL DBA für Verbindungsverwaltung](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
# io/aurora\$1redo\$1log\$1flush
Dieses `io/aurora_redo_log_flush`-Ereignis tritt ein, wenn eine Sitzung persistente Daten in den Amazon-Aurora-Speicher schreibt.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.io-auredologflush.context.supported)
+ [Kontext](#ams-waits.io-auredologflush.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.io-auredologflush.causes)
+ [Aktionen](#ams-waits.io-auredologflush.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Version 2
## Kontext
Das `io/aurora_redo_log_flush` Ereignis bezieht sich auf einen Schreibvorgang input/output (I/O) in Aurora MySQL.
**Anmerkung**
In Version 3 von Aurora MySQL heißt dieses Warteereignis [io/redo\$1log\$1flush](ams-waits.io-redologflush.md).
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Aus Gründen der Datenpersistenz erfordern Commits ein dauerhaftes Schreiben in einen stabilen Speicher. Wenn die Datenbank zu viele Commits durchführt, gibt es bei der I/O Schreiboperation ein Wartungsereignis, das `io/aurora_redo_log_flush` Wait-Ereignis.
In den folgenden Beispielen werden 50 000 Datensätze mithilfe der db.r5.xlarge DB-Instance-Klasse in einen Aurora-MySQL-DB-Cluster eingefügt:
+ Im ersten Beispiel fügt jede Sitzung zeilenweise 10 000 Datensätze ein. Wenn sich ein DML-Befehl (Data Manipulation Language) nicht innerhalb einer Transaktion befindet, verwendet Aurora MySQL standardmäßig implizite Commits. Autocommit ist aktiviert. Dies bedeutet, dass für jede Zeileneinfügung ein Commit vorhanden ist. Performance Insights zeigt, dass die Verbindungen die meiste Zeit damit verbringen, auf das `io/aurora_redo_log_flush`-Warteereignis zu warten.
![\[Beispiel für Performance Insights für das Warteereignis\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)
Dies wird durch die verwendeten einfachen Einfügungsanweisungen verursacht.
![\[Einfügungsanweisungen in Top-SQL\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)
Die 50 000 Datensätze benötigen 3,5 Minuten, um eingefügt zu werden.
+ Im zweiten Beispiel werden Einfügungen in 1 000 Batches vorgenommen, d.h. jede Verbindung führt 10 Commits statt 10 000 aus. Performance Insights zeigt, dass die Verbindungen nicht die meiste Zeit mit dem `io/aurora_redo_log_flush`-Warteereignis verbringen.
![\[Performance-Insights-Beispiel für das Warteereignis, das weniger Auswirkungen hat\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)
Die 50 000 Datensätze benötigen 4 Sekunden, um eingefügt zu werden.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Identifizieren Sie die problematischen Sitzungen und Abfragen](#ams-waits.io-auredologflush.actions.identify-queries)
+ [Gruppieren Sie Ihre Schreiboperationen](#ams-waits.io-auredologflush.actions.action0)
+ [Deaktivieren Sie Autocommit](#ams-waits.io-auredologflush.actions.action1)
+ [Transaktionen verwenden](#ams-waits.io-auredologflush.action2)
+ [Verwenden von Batches](#ams-waits.io-auredologflush.action3)
### Identifizieren Sie die problematischen Sitzungen und Abfragen
Wenn Ihre DB-Instance einen Engpass hat, besteht Ihre erste Aufgabe darin, die Sitzungen und Abfragen zu finden, die ihn verursachen. Einen nützlichen AWS Datenbank-Blogbeitrag finden Sie unter [Analysieren von Amazon Aurora MySQL-Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
**So identifizieren Sie Sitzungen und Abfragen, die einen Engpass verursachen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie Ihre DB-Instance aus.
1. Wählen Sie unter **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unten auf der Seite **Top-SQL** aus.
Die Abfragen oben in der Liste verursachen die höchste Belastung der Datenbank.
### Gruppieren Sie Ihre Schreiboperationen
Die folgenden Beispiele lösen das `io/aurora_redo_log_flush`-Warteereignis aus. (Autocommit ist aktiviert.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Um die Wartezeit auf das `io/aurora_redo_log_flush`-Wartezeitereignis zu verkürzen, gruppieren Sie Ihre Schreibvorgänge logisch in einem einzigen Commit, um persistente Speicheraufrufe zu reduzieren.
### Deaktivieren Sie Autocommit
Deaktivieren Sie Autocommit, bevor Sie große Änderungen vornehmen, die nicht in einer Transaktion enthalten sind, wie im folgenden Beispiel gezeigt.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Transaktionen verwenden
Sie können Transaktionen verwenden, wie im folgenden Beispiel gezeigt.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Verwenden von Batches
Sie können Änderungen in Batches vornehmen, wie im folgenden Beispiel gezeigt. Die Verwendung zu großer Batches kann jedoch zu Leistungsproblemen führen, insbesondere bei Read Replicas oder bei der point-in-time Wiederherstellung (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
Das `io/aurora_respond_to_client`-Ereignis tritt auf, wenn ein Thread darauf wartet, eine Ergebnismenge an einen Client zurückzugeben.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.respond-to-client.context.supported)
+ [Kontext](#ams-waits.respond-to-client.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.respond-to-client.causes)
+ [Aktionen](#ams-waits.respond-to-client.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Version 2
## Kontext
Das Ereignis `io/aurora_respond_to_client` zeigt an, dass ein Thread darauf wartet, eine Ergebnismenge an einen Client zurückzugeben.
Die Abfrageverarbeitung ist abgeschlossen und die Ergebnisse werden an den Anwendungsclient zurückgegeben. Da jedoch nicht genügend Netzwerkbandbreite im DB-Cluster vorhanden ist, wartet ein Thread darauf, die Ergebnismenge zurückzugeben.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `io/aurora_respond_to_client`-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
**DB-Instance-Klasse reicht für die Workload nicht aus**
Die vom DB-Cluster verwendete DB-Instance-Klasse verfügt nicht über die erforderliche Netzwerkbandbreite, um die Workload effizient zu verarbeiten.
**Große Ergebnismengen**
Es gab eine Zunahme der Größe der zurückgegebenen Ergebnismenge, da die Abfrage eine höhere Anzahl von Zeilen zurückgibt. Die größere Ergebnismenge verbraucht mehr Netzwerkbandbreite.
**Erhöhte Belastung des Clients**
Auf dem Client kann es zu CPU-, Speicher- oder Netzwerksättigung kommen. Eine Erhöhung der Belastung des Clients verzögert den Empfang von Daten aus dem Aurora-MySQL-DB-Cluster.
**Erhöhte Netzwerklatenz**
Es kann zu einer erhöhten Netzwerklatenz zwischen dem Aurora-MySQL-DB-Cluster und dem Client kommen. Eine höhere Netzwerklatenz erhöht die Zeit, die der Client benötigt, um die Daten zu empfangen.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen](#ams-waits.respond-to-client.actions.identify)
+ [Skalieren Sie die DB-Instance-Klasse](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [Überprüfen Sie die Workload auf unerwartete Ergebnisse](#ams-waits.respond-to-client.actions.workload)
+ [Verteilen Sie die Workload mit Leser-Instances](#ams-waits.respond-to-client.actions.balance)
+ [Verwenden Sie den Modifikator SQL\$1BUFFER\$1RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)
### Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen
Sie können Performance Insights verwenden, um Abfragen anzuzeigen, die durch das `io/aurora_respond_to_client`-Warteereignis gesperrt wurden Normalerweise weisen Datenbanken mit mäßiger bis erheblicher Last Warteereignisse auf. Die Warteereignisse sind möglicherweise akzeptabel, wenn die Leistung optimal ist. Wenn die Leistung nicht optimal ist, untersuchen Sie, wo die Datenbank die meiste Zeit verbringt. Schauen Sie sich die Warteereignisse an, die zur höchsten Belastung beitragen und finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.
**So suchen Sie SQL-Abfragen, die für hohe Last verantwortlich sind**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
1. Wählen Sie im Diagramm zur **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unten auf der Seite **Top-SQL** aus.
Das Diagramm listet die SQL-Abfragen auf, die für die Belastung verantwortlich sind. Diejenigen, die an der Spitze der Liste stehen, sind am meisten verantwortlich. Konzentrieren Sie sich auf diese Aussagen, um einen Engpass zu beheben.
Einen nützlichen Überblick über die Fehlerbehebung mit Performance Insights finden Sie im AWS Datenbank-Blogbeitrag [Analysieren von Amazon Aurora MySQL-Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Skalieren Sie die DB-Instance-Klasse
Prüfen Sie, ob der Wert der CloudWatch Amazon-Metriken in Bezug auf den Netzwerkdurchsatz gestiegen ist, z. B. `NetworkReceiveThroughput` und`NetworkTransmitThroughput`. Wenn die Netzwerkbandbreite der DB-Instance-Klasse erreicht wird, können Sie die vom DB-Cluster verwendete DB-Instance-Klasse skalieren, indem Sie den DB-Cluster ändern. Eine DB-Instance-Klasse mit größerer Netzwerkbandbreite gibt Daten effizienter an Clients zurück.
Informationen zur Überwachung von CloudWatch Amazon-Metriken finden Sie unter[Anzeigen von Metriken in der Amazon-RDS-Konsole](USER_Monitoring.md). Weitere Informationen zu DB-Instance-Klassen finden Sie unter [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md). Weitere Informationen zum Ändern eines DB-Clusters finden Sie unter [Ändern eines Amazon Aurora-DB-Clusters](Aurora.Modifying.md).
### Überprüfen Sie die Workload auf unerwartete Ergebnisse
Überprüfen Sie die Workload im DB-Cluster und stellen Sie sicher, dass keine unerwarteten Ergebnisse erzielt werden. Beispielsweise kann es Abfragen geben, die eine höhere Anzahl von Zeilen als erwartet zurückgeben. In diesem Fall können Sie Performance-Insights-Zählermetriken wie `Innodb_rows_read` verwenden. Weitere Informationen finden Sie unter [Performance-Insights-Zählermetriken](USER_PerfInsights_Counters.md).
### Verteilen Sie die Workload mit Leser-Instances
Sie können schreibgeschützte Workloads mit Aurora-Replikaten verteilen. Sie können horizontal skalieren, indem Sie weitere Aurora-Replikate hinzufügen. Dies kann zu einer Erhöhung der Drosselgrenzen für die Netzwerkbandbreite führen. Weitere Informationen finden Sie unter [Amazon-Aurora-DB-Cluster](Aurora.Overview.md).
### Verwenden Sie den Modifikator SQL\$1BUFFER\$1RESULT
Sie können `SELECT`-Anweisungen den Modifikator `SQL_BUFFER_RESULT` hinzufügen, um das Ergebnis in eine temporäre Tabelle zu zwingen, bevor es an den Client zurückgegeben wird. Dieser Modifikator kann bei Leistungsproblemen helfen, wenn InnoDB-Sperren nicht freigegeben werden, weil sich Abfragen im Wartezustand `io/aurora_respond_to_client` befinden. Weitere Informationen finden Sie unter [SELECT-Anweisung](https://dev.mysql.com/doc/refman/5.7/en/select.html) in der MySQL-Dokumentation.
# io/redo\$1log\$1flush
Dieses `io/redo_log_flush`-Ereignis tritt ein, wenn eine Sitzung persistente Daten in den Amazon-Aurora-Speicher schreibt.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.io-redologflush.context.supported)
+ [Kontext](#ams-waits.io-redologflush.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.io-redologflush.causes)
+ [Aktionen](#ams-waits.io-redologflush.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Version 3
## Kontext
Das `io/redo_log_flush` Ereignis bezieht sich auf einen Schreibvorgang input/output (I/O) in Aurora MySQL.
**Anmerkung**
In Aurora MySQL Version 2 heißt dieses Warteereignis [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Aus Gründen der Datenpersistenz erfordern Commits ein dauerhaftes Schreiben in einen stabilen Speicher. Wenn die Datenbank zu viele Commits durchführt, gibt es bei der I/O Schreiboperation ein Wartungsereignis, das `io/redo_log_flush` Wait-Ereignis.
Beispiele für das Verhalten dieses Warteereignisses finden Sie unter [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Identifizieren Sie die problematischen Sitzungen und Abfragen](#ams-waits.io-redologflush.actions.identify-queries)
+ [Gruppieren Sie Ihre Schreiboperationen](#ams-waits.io-redologflush.actions.action0)
+ [Deaktivieren Sie Autocommit](#ams-waits.io-redologflush.actions.action1)
+ [Transaktionen verwenden](#ams-waits.io-redologflush.action2)
+ [Verwenden von Batches](#ams-waits.io-redologflush.action3)
### Identifizieren Sie die problematischen Sitzungen und Abfragen
Wenn Ihre DB-Instance einen Engpass hat, besteht Ihre erste Aufgabe darin, die Sitzungen und Abfragen zu finden, die ihn verursachen. Einen nützlichen AWS Datenbank-Blogbeitrag finden Sie unter [Analysieren von Amazon Aurora MySQL-Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
**So identifizieren Sie Sitzungen und Abfragen, die einen Engpass verursachen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie Ihre DB-Instance aus.
1. Wählen Sie unter **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unten auf der Seite **Top-SQL** aus.
Die Abfragen oben in der Liste verursachen die höchste Belastung der Datenbank.
### Gruppieren Sie Ihre Schreiboperationen
Die folgenden Beispiele lösen das `io/redo_log_flush`-Warteereignis aus. (Autocommit ist aktiviert.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Um die Wartezeit auf das `io/redo_log_flush`-Wartezeitereignis zu verkürzen, gruppieren Sie Ihre Schreibvorgänge logisch in einem einzigen Commit, um persistente Speicheraufrufe zu reduzieren.
### Deaktivieren Sie Autocommit
Deaktivieren Sie Autocommit, bevor Sie große Änderungen vornehmen, die nicht in einer Transaktion enthalten sind, wie im folgenden Beispiel gezeigt.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Transaktionen verwenden
Sie können Transaktionen verwenden, wie im folgenden Beispiel gezeigt.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Verwenden von Batches
Sie können Änderungen in Batches vornehmen, wie im folgenden Beispiel gezeigt. Die Verwendung zu großer Batches kann jedoch zu Leistungsproblemen führen, insbesondere bei Read Replicas oder bei der point-in-time Wiederherstellung (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
Dieses `io/socket/sql/client_connection`-Ereignis tritt auf, wenn ein Thread gerade eine neue Verbindung verarbeitet.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.client-connection.context.supported)
+ [Kontext](#ams-waits.client-connection.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.client-connection.causes)
+ [Aktionen](#ams-waits.client-connection.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Versionen 2 und 3
## Kontext
Das `io/socket/sql/client_connection`-Ereignis zeigt an, dass mysqld damit beschäftigt ist, Threads zu erstellen, um eingehende neue Clientverbindungen zu verarbeiten. In diesem Szenario verlangsamt sich die Verarbeitung neuer Clientverbindungsanfragen, während Verbindungen warten, bis der Thread zugewiesen wird. Weitere Informationen finden Sie unter [MySQL-Server (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld).
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
+ Es gibt einen plötzlichen Anstieg neuer Benutzerverbindungen von der Anwendung zu Ihrer Amazon-RDS-Instance.
+ Ihre DB-Instance kann keine neuen Verbindungen verarbeiten, da das Netzwerk, die CPU oder der Speicher gedrosselt werden.
## Aktionen
Wenn `io/socket/sql/client_connection` die Datenbankaktivität dominiert, weist dies nicht unbedingt auf ein Leistungsproblem hin. In einer Datenbank, die nicht im Leerlauf ist, ist ein Warteereignis immer im Vordergrund. Handeln Sie nur, wenn die Leistung nachlässt. Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir unterschiedliche Maßnahmen.
**Topics**
+ [Identifizieren Sie die problematischen Sitzungen und Abfragen](#ams-waits.client-connection.actions.identify-queries)
+ [Befolgen Sie die bewährten Methoden für die Verbindungsverwaltung](#ams-waits.client-connection.actions.manage-connections)
+ [Vergrößern Sie Ihre Instance, wenn Ressourcen gedrosselt werden](#ams-waits.client-connection.upgrade)
+ [Prüfen Sie die Top-Hosts und Top-Benutzer](#ams-waits.client-connection.top-hosts)
+ [Fragen Sie die performance\$1schema-Tabellen ab](#ams-waits.client-connection.perf-schema)
+ [Prüfen Sie die Thread-Zustand Ihrer Abfragen](#ams-waits.client-connection.thread-states)
+ [Prüfen Sie Ihre Anfragen und Abfragen](#ams-waits.client-connection.auditing)
+ [Kombinieren Sie Ihre Datenbankverbindungen](#ams-waits.client-connection.pooling)
### Identifizieren Sie die problematischen Sitzungen und Abfragen
Wenn Ihre DB-Instance einen Engpass hat, besteht Ihre erste Aufgabe darin, die Sitzungen und Abfragen zu finden, die ihn verursachen. Einen nützlichen Blogbeitrag finden Sie unter [Analysieren von Amazon-Aurora-MySQL-Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
**So identifizieren Sie Sitzungen und Abfragen, die einen Engpass verursachen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie Ihre DB-Instance aus.
1. Wählen Sie unter **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unten auf der Seite **Top-SQL** aus.
Die Abfragen oben in der Liste verursachen die höchste Belastung der Datenbank.
### Befolgen Sie die bewährten Methoden für die Verbindungsverwaltung
Berücksichtigen Sie die folgenden Strategien, um Ihre Verbindungen zu verwalten:
+ Verwenden Sie Verbindungspooling.
Sie können die Anzahl der Verbindungen nach Bedarf schrittweise erhöhen. Weitere Informationen finden Sie im Whitepaper [Amazon-Aurora-MySQL-Datenbankadministratorhandbuch](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
+ Verwenden Sie einen Reader-Knoten, um schreibgeschützten Datenverkehr umzuverteilen.
Weitere Informationen erhalten Sie unter [Aurora-Replikate](Aurora.Replication.md#Aurora.Replication.Replicas) und [Amazon-Aurora-Endpunktverbindungen](Aurora.Overview.Endpoints.md).
### Vergrößern Sie Ihre Instance, wenn Ressourcen gedrosselt werden
Suchen Sie nach Beispielen für die Drosselung in den folgenden Ressourcen:
+ CPU
Überprüfen Sie Ihre CloudWatch Amazon-Metriken auf hohe CPU-Auslastung.
+ Netzwerk
Prüfen Sie, ob der Wert der CloudWatch Messwerte gestiegen ist `network receive throughput` und`network transmit throughput`. Wenn Ihre Instance das Netzwerkbandbreitenlimit für Ihre Instance-Klasse erreicht hat, sollten Sie Ihre RDS-Instance auf einen höheren Instance-Klassentyp skalieren. Weitere Informationen finden Sie unter [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md).
+ Freisetzbarer Speicher
Prüfen Sie, ob die CloudWatch Metrik gesunken ist`FreeableMemory`. Ziehen Sie auch in Erwägung, die erweiterte Überwachung zu aktivieren. Weitere Informationen finden Sie unter [Überwachen von Betriebssystem-Metriken mithilfe von „Enhanced Monitoring“·(Erweiterte·Überwachung)](USER_Monitoring.OS.md).
### Prüfen Sie die Top-Hosts und Top-Benutzer
Verwenden Sie Performance Insights, um die Top-Hosts und Top-Benutzer zu überprüfen. Weitere Informationen finden Sie unter [Analyse der Metriken mit dem Performance-Insights-Dashboard](USER_PerfInsights.UsingDashboard.md).
### Fragen Sie die performance\$1schema-Tabellen ab
Um eine genaue Anzahl der aktuellen und gesamten Verbindungen zu erhalten, fragen Sie die `performance_schema`-Tabellen ab. Mit dieser Technik identifizieren Sie den Quellbenutzer oder Host, der für das Erstellen einer hohen Anzahl von Verbindungen verantwortlich ist. Fragen Sie die `performance_schema`-Tabellen beispielsweise wie folgt ab.
```
SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;
```
### Prüfen Sie die Thread-Zustand Ihrer Abfragen
Wenn Ihr Leistungsproblem andauert, überprüfen Sie die Thread-Zustand Ihrer Abfragen. Geben Sie im `mysql`-Client den folgenden Befehl aus.
```
show processlist;
```
### Prüfen Sie Ihre Anfragen und Abfragen
Verwenden Sie AuroraAurora MySQL Advanced Auditing, um die Art der Anfragen und Abfragen von Benutzerkonten zu überprüfen. Weitere Informationen zum Aktivieren der Prüfung finden Sie unter [Verwenden von Advanced Auditing in einem Amazon Aurora MySQL DB-Cluster](AuroraMySQL.Auditing.md).
### Kombinieren Sie Ihre Datenbankverbindungen
Erwägen Sie, Amazon RDS Proxy für die Verbindungsverwaltung zu verwenden. Durch die Verwendung von RDS Proxy können Sie Ihren Anwendungen erlauben, Datenbankverbindungen zu bündeln und gemeinsam zu nutzen, um ihre Skalierbarkeit zu verbessern. RDS-Proxy macht Anwendungen widerstandsfähiger gegenüber Datenbankfehlern, indem er automatisch eine Verbindung zu einer Standby-DB-Instance herstellt, während Anwendungsverbindungen erhalten bleiben. Weitere Informationen finden Sie unter [Amazon RDS-Proxy für Aurora](rds-proxy.md).
# io/table/sql/handler
Dieses `io/table/sql/handler`-Ereignis tritt ein, wenn Arbeit an eine Speicher-Engine delegiert wurde.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.waitio.context.supported)
+ [Kontext](#ams-waits.waitio.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.waitio.causes)
+ [Aktionen](#ams-waits.waitio.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Versionen 2 und 3
## Kontext
Das `io/table`-Ereignis zeigt ein Warten auf den Zugriff auf eine Tabelle an. Dieses Ereignis tritt unabhängig davon auf, ob die Daten im Pufferpool zwischengespeichert werden oder über die Festplatte darauf zugegriffen wird. Das `io/table/sql/handler`-Ereignis weist auf eine Zunahme der Workload-Aktivität hin.
Ein *Handler* ist eine Routine, die auf eine bestimmte Art von Daten spezialisiert ist oder sich auf bestimmte spezielle Aufgaben konzentriert. Beispielsweise empfängt und verdaut ein Ereignis-Handler Ereignisse und Signale vom Betriebssystem oder von einer Benutzeroberfläche. Ein Speicherhandler führt Aufgaben im Zusammenhang mit dem Speicher aus. Ein Dateieingabe-Handler ist eine Funktion, die Dateieingaben empfängt und je nach Kontext spezielle Aufgaben für die Daten ausführt.
Ansichten wie `performance_schema.events_waits_current` zeigen oft `io/table/sql/handler` an, wenn das eigentliche Warten ein verschachteltes Warteereignis wie eine Sperre ist. Wenn das tatsächliche Warten nicht `io/table/sql/handler` ist, meldet Performance Insights das verschachtelte Warteereignis. Wenn Performance Insights berichtet`io/table/sql/handler`, handelt es sich um die InnoDB-Verarbeitung der I/O Anfrage und nicht um ein verstecktes verschachteltes Warteereignis. Weitere Informationen finden Sie unter [Leistungsschema-Atom- und Molekülereignisse](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) im *MySQL-Referenzhandbuch*.
Das `io/table/sql/handler` Ereignis tritt häufig in Ereignissen mit höchsten Wartezeiten auf, I/O z. B. `io/aurora_redo_log_flush`
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
In Performance Insights weisen plötzliche Spitzen im `io/table/sql/handler`-Ereignis auf eine Zunahme der Workload-Aktivität hin. Erhöhte Aktivität bedeutet eine erhöhte I/O.
Performance Insights filtert das Verschachtelungsereignis IDs und meldet keine `io/table/sql/handler` Wartezeit, wenn es sich bei dem zugrunde liegenden verschachtelten Ereignis um ein Lock-Wait handelt. Wenn beispielsweise das Grundursachenereignis [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) ist, zeigt Performance Insights diese Wartezeit in den Top-Warteereignissen an und nicht `io/table/sql/handler`.
In Ansichten wie `performance_schema.events_waits_current` werden Wartezeiten für `io/table/sql/handler` oft angezeigt, wenn das eigentliche Warten ein verschachteltes Warteereignis wie eine Sperre ist. Wenn die tatsächliche Wartezeit von `io/table/sql/handler` abweicht, schlägt Performance Insights die verschachtelte Wartezeit nach und meldet die tatsächliche Wartezeit anstelle von `io/table/sql/handler`. Wenn Performance Insights `io/table/sql/handler` meldet, ist die tatsächliche Wartezeit `io/table/sql/handler` und kein verstecktes verschachteltes Warteereignis. Weitere Informationen finden Sie unter [Leistungsschema-Atom- und Molekülereignisse](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) im *MySQL-Referenzhandbuch 5.7*.
## Aktionen
Wenn das Warteereignis die Datenbankaktivität dominiert, weist dies nicht unbedingt auf ein Leistungsproblem hin. Ein Warteereignis ist immer im Vordergrund, wenn die Datenbank aktiv ist. Sie müssen nur handeln, wenn sich die Leistung verschlechtert.
Abhängig von den anderen angezeigten Warteereignissen empfehlen wir unterschiedliche Aktionen.
**Topics**
+ [Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen](#ams-waits.waitio.actions.identify)
+ [Überprüfen Sie, ob eine Korrelation mit den Performance-Insights-Zählermetriken vorliegt](#ams-waits.waitio.actions.filters)
+ [Nach anderen korrelierten Warteereignissen suchen](#ams-waits.waitio.actions.maintenance)
### Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen
Normalerweise weisen Datenbanken mit mäßiger bis erheblicher Last Warteereignisse auf. Die Warteereignisse sind möglicherweise akzeptabel, wenn die Leistung optimal ist. Wenn die Leistung nicht optimal ist, untersuchen Sie, wo die Datenbank die meiste Zeit verbringt. Schauen Sie sich die Warteereignisse an, die zur höchsten Belastung beitragen und finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.
**So suchen Sie SQL-Abfragen, die für hohe Last verantwortlich sind**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
1. Wählen Sie im Diagramm zur **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unten auf der Seite **Top-SQL** aus.
Das Diagramm listet die SQL-Abfragen auf, die für die Belastung verantwortlich sind. Diejenigen, die an der Spitze der Liste stehen, sind am meisten verantwortlich. Konzentrieren Sie sich auf diese Aussagen, um einen Engpass zu beheben.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag [Analysieren Sie Amazon Aurora MySQL Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Überprüfen Sie, ob eine Korrelation mit den Performance-Insights-Zählermetriken vorliegt
Suchen Sie nach Performance-Insights-Zählermetriken wie `Innodb_rows_changed`. Wenn Zählermetriken mit `io/table/sql/handler` korreliert sind, gehen Sie folgendermaßen vor:
1. Suchen Sie in Performance Insights nach den SQL-Anweisungen, die das `io/table/sql/handler`-Top-Warteereignis berücksichtigen. Optimieren Sie diese Anweisung, wenn möglich, damit sie weniger Zeilen zurückgibt.
1. Rufen Sie die obersten Tabellen aus den `schema_table_statistics`- und `x$schema_table_statistics`-Ansichten ab. Diese Ansichten zeigen den Zeitaufwand pro Tabelle an. Weitere Informationen finden Sie unter [Die Ansichten schema\$1table\$1statistics und x\$1schema\$1table\$1statistics](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html) im *MySQL-Referenzhandbuch*.
Standardmäßig werden Zeilen nach absteigender Gesamtwartezeit sortiert. Tabellen mit dem größten Streit erscheinen zuerst. Die Ausgabe gibt an, ob Zeit für Lese-, Schreibvorgänge, Abrufe, Einfügungen, Aktualisierungen oder Löschungen aufgewendet wird.
```
mysql> select * from sys.schema_table_statistics limit 1\G
*************************** 1. row ***************************
table_schema: read_only_db
table_name: sbtest41
total_latency: 54.11 m
rows_fetched: 6001557
fetch_latency: 39.14 m
rows_inserted: 14833
insert_latency: 5.78 m
rows_updated: 30470
update_latency: 5.39 m
rows_deleted: 14833
delete_latency: 3.81 m
io_read_requests: NULL
io_read: NULL
io_read_latency: NULL
io_write_requests: NULL
io_write: NULL
io_write_latency: NULL
io_misc_requests: NULL
io_misc_latency: NULL
1 row in set (0.11 sec)
```
### Nach anderen korrelierten Warteereignissen suchen
Wenn `synch/sxlock/innodb/btr_search_latch` und `io/table/sql/handler` zusammen am meisten zur DB-Ladeanomalie beitragen, prüfen Sie, ob die Variable `innodb_adaptive_hash_index` aktiviert ist. Wenn dies der Fall ist, sollten Sie den `innodb_adaptive_hash_index_parts`-Parameterwert erhöhen.
Wenn der Adaptive-Hash-Index ausgeschaltet, erwägen Sie, ihn einzuschalten. Weitere Informationen zum MySQL-Adaptive-Hash-Index finden Sie in den folgenden Ressourcen:
+ Der Artikel [Ist der Adaptive-Hash-Index in InnoDB für meinen Workload geeignet?](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload) auf der Percona-Website
+ [Adaptive-Hash-Index](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html) im *MySQL-Referenzhandbuch*
+ Der Artikel [Verbindung in MySQL InnoDB: Nützliche Informationen aus der Semaphores-Sektion](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/) auf der Percona-Website
**Anmerkung**
Der Adaptive-Hash-Index wird auf Aurora-Reader-DB-Instances nicht unterstützt.
In einigen Fällen kann die Leistung auf einer Reader-Instance schwach sein, wenn `synch/sxlock/innodb/btr_search_latch` und `io/table/sql/handler` dominant sind. Wenn ja, erwägen Sie, die Workload vorübergehend auf die Writer-DB-Instance umzuleiten und den Adaptive-Hash-Index zu aktivieren.
# synch/cond/innodb/row\$1sperren\$1warten
Das `synch/cond/innodb/row_lock_wait`-Ereignis tritt auf, wenn eine Sitzung eine Zeile für ein Update gesperrt hat und eine andere Sitzung versucht, dieselbe Zeile zu aktualisieren. Weitere Informationen finden Sie unter [InnoDB Locking](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) in der MySQL-Dokumentation.
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Version 3
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Mehrere DML-Anweisungen (Data Manipulation Language) greifen gleichzeitig auf dieselbe Zeile oder dieselben Zeilen zu.
## Aktionen
Abhängig von den anderen angezeigten Warteereignissen empfehlen wir unterschiedliche Aktionen.
**Topics**
+ [Finden und antworten Sie auf die SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind](#ams-waits.row-lock-wait.actions.id)
+ [Suchen und antworten Sie auf die Blockiersitzung](#ams-waits.row-lock-wait.actions.blocker)
### Finden und antworten Sie auf die SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind
Verwenden Sie Performance Insights, um die SQL-Anweisungen zu identifizieren, die für dieses Warteereignis verantwortlich sind. Berücksichtigen Sie dabei die folgenden Strategien:
+ Wenn Zeilensperren ein dauerhaftes Problem darstellen, erwägen Sie, die Anwendung neu zu schreiben, um eine optimistische Sperre zu verwenden.
+ Verwenden Sie mehrzeilige Anweisungen.
+ Verteilen Sie die Workload auf verschiedene Datenbankobjekte. Sie können dazu die Partitionierung verwenden.
+ Prüfen Sie den Wert des `innodb_lock_wait_timeout`-Parameters. Es steuert, wie lange Transaktionen warten, bevor ein Timeout-Fehler generiert wird.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag [Analysieren Sie Amazon Aurora MySQL Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Suchen und antworten Sie auf die Blockiersitzung
Stellen Sie fest, ob die Blockiersitzung im Leerlauf oder aktiv ist. Finden Sie außerdem heraus, ob die Sitzung von einer Anwendung oder einem aktiven Benutzer stammt.
Um die Sitzung zu identifizieren, die die Sperre hält, können Sie `SHOW ENGINE INNODB STATUS` ausführen. Das folgende Beispiel zeigt eine Beispielausgabe.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
Oder Sie können die folgende Abfrage verwenden, um Details zu aktuellen Sperren zu extrahieren.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_id = it.trx_id join information_schema.processlist p
ON it.trx_mysql_thread_id = p.id join information_schema.innodb_trx it1
ON ilw.requesting_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
Wenn Sie die Sitzung identifizieren, umfassen Ihre Optionen die Folgenden:
+ Wenden Sie sich an den Besitzer der Anwendung oder den Benutzer.
+ Wenn die Sperrsitzung im Leerlauf ist, erwägen Sie, die Sperrsitzung zu beenden. Diese Aktion könnte einen langen Rollback auslösen. Informationen zum Beenden einer Sitzung finden Sie unter [Beenden einer Sitzung oder Abfrage](mysql-stored-proc-ending.md).
Weitere Informationen zum Identifizieren blockierender Transaktionen finden Sie unter [Verwenden von InnoDB-Transaktions- und Sperrinformationen](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html) in der MySQL-Dokumentation.
# synch/cond/innodb/row\$1lock\$1wait\$1cond
Das `synch/cond/innodb/row_lock_wait_cond`-Ereignis tritt auf, wenn eine Sitzung eine Zeile für ein Update gesperrt hat und eine andere Sitzung versucht, dieselbe Zeile zu aktualisieren. Weitere Informationen finden Sie unter [InnoDB Locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) in der MySQL-Dokumentation.
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Version 2
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Mehrere DML-Anweisungen (Data Manipulation Language) greifen gleichzeitig auf dieselbe Zeile oder dieselben Zeilen zu.
## Aktionen
Abhängig von den anderen angezeigten Warteereignissen empfehlen wir unterschiedliche Aktionen.
**Topics**
+ [Finden und antworten Sie auf die SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind](#ams-waits.row-lock-wait-cond.actions.id)
+ [Suchen und antworten Sie auf die Blockiersitzung](#ams-waits.row-lock-wait-cond.actions.blocker)
### Finden und antworten Sie auf die SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind
Verwenden Sie Performance Insights, um die SQL-Anweisungen zu identifizieren, die für dieses Warteereignis verantwortlich sind. Berücksichtigen Sie dabei die folgenden Strategien:
+ Wenn Zeilensperren ein dauerhaftes Problem darstellen, erwägen Sie, die Anwendung neu zu schreiben, um eine optimistische Sperre zu verwenden.
+ Verwenden Sie mehrzeilige Anweisungen.
+ Verteilen Sie die Workload auf verschiedene Datenbankobjekte. Sie können dazu die Partitionierung verwenden.
+ Prüfen Sie den Wert des `innodb_lock_wait_timeout`-Parameters. Es steuert, wie lange Transaktionen warten, bevor ein Timeout-Fehler generiert wird.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag [Analysieren Sie Amazon Aurora MySQL Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Suchen und antworten Sie auf die Blockiersitzung
Stellen Sie fest, ob die Blockiersitzung im Leerlauf oder aktiv ist. Finden Sie außerdem heraus, ob die Sitzung von einer Anwendung oder einem aktiven Benutzer stammt.
Um die Sitzung zu identifizieren, die die Sperre hält, können Sie `SHOW ENGINE INNODB STATUS` ausführen. Das folgende Beispiel zeigt eine Beispielausgabe.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
Oder Sie können die folgende Abfrage verwenden, um Details zu aktuellen Sperren zu extrahieren.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Wenn Sie die Sitzung identifizieren, umfassen Ihre Optionen die Folgenden:
+ Wenden Sie sich an den Besitzer der Anwendung oder den Benutzer.
+ Wenn die Sperrsitzung im Leerlauf ist, erwägen Sie, die Sperrsitzung zu beenden. Diese Aktion könnte einen langen Rollback auslösen. Informationen zum Beenden einer Sitzung finden Sie unter [Beenden einer Sitzung oder Abfrage](mysql-stored-proc-ending.md).
Weitere Informationen zum Identifizieren blockierender Transaktionen finden Sie unter [Verwenden von InnoDB-Transaktions- und Sperrinformationen](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) in der MySQL-Dokumentation.
# synch/cond/sql/MDL\$1context: :cond\$1wait\$1status
Dieses `synch/cond/sql/MDL_context::COND_wait_status`-Ereignis tritt ein, wenn Threads auf eine Tabellenmetadatensperre warten.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.cond-wait-status.context.supported)
+ [Kontext](#ams-waits.cond-wait-status.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.cond-wait-status.causes)
+ [Aktionen](#ams-waits.cond-wait-status.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Versionen 2 und 3
## Kontext
Das `synch/cond/sql/MDL_context::COND_wait_status`-Ereignis zeigt an, dass Threads auf eine Tabellenmetadatensperre warten. In einigen Fällen hält eine Sitzung eine Metadatensperre für eine Tabelle und eine andere Sitzung versucht, dieselbe Sperre für dieselbe Tabelle zu erhalten. In einem solchen Fall wartet die zweite Sitzung auf das `synch/cond/sql/MDL_context::COND_wait_status`-Warteereignis.
MySQL verwendet die Sperre von Metadaten, um den gleichzeitigen Zugriff auf Datenbankobjekte zu verwalten und die Datenkonsistenz sicherzustellen. Das Sperren von Metadaten gilt für Tabellen, Schemata, geplante Ereignisse, Tablespaces und Benutzersperren, die mit der `get_lock`-Funktion erworben wurden, und gespeicherte Programme. Gespeicherte Programme umfassen Prozeduren, Funktionen und Auslöser. Weitere Informationen finden Sie unter [Metadata Locking](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html) in der MySQL-Dokumentation.
Die MySQL-Prozessliste zeigt diese Sitzung im Zustand `waiting for metadata lock`. Wenn in Performance Insights `Performance_schema` aktiviert ist, wird das Ereignis `synch/cond/sql/MDL_context::COND_wait_status` angezeigt.
Das Standardtimeout für eine Abfrage, die auf eine Metadatensperre wartet, basiert auf dem Wert des `lock_wait_timeout`-Parameters, der standardmäßig 31.536.000 Sekunden (365 Tage) beträgt.
Weitere Informationen zu verschiedenen InnoDB-Sperren und den Arten von Sperren, die Konflikte verursachen können, finden Sie unter [InnoDB-Sperren](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) in der MySQL-Dokumentation.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `synch/cond/sql/MDL_context::COND_wait_status`-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
**Langlebige Transaktionen**
Eine oder mehrere Transaktionen ändern eine große Datenmenge und halten Tabellen für eine sehr lange Zeit gesperrt.
**Leerlauf-Transaktionen**
Eine oder mehrere Transaktionen bleiben lange offen, ohne festgeschrieben oder rückgängig gemacht zu werden.
**DDL-Anweisungen zu großen Tabellen**
Für sehr große Tabellen wurden eine oder mehrere DDL-Anweisungen (Data Definition Statements) ausgeführt, z. B. `ALTER TABLE`-Befehle.
**Explizite Tabellensperren**
Es gibt explizite Sperren für Tabellen, die nicht zeitnah freigegeben werden. Beispielsweise kann eine Anwendung `LOCK TABLE`-Anweisungen nicht ordnungsgemäß ausführen.
## Aktionen
Wir empfehlen verschiedene Aktionen, abhängig von den Ursachen Ihres Warteereignisses und von der Version des Aurora-MySQL-DB-Clusters.
**Topics**
+ [Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen](#ams-waits.cond-wait-status.actions.identify)
+ [Nach vergangenen Ereignissen suchen](#ams-waits.cond-wait-status.actions.past-events)
+ [Führen Sie Anfragen für Aurora MySQL Version 2 aus](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57)
+ [Antworten Sie auf die Blockiersitzung](#ams-waits.cond-wait-status.actions.blocker)
### Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen
Sie können Performance Insights verwenden, um Abfragen anzuzeigen, die durch das `synch/cond/sql/MDL_context::COND_wait_status`-Warteereignis gesperrt wurden Um jedoch die blockierende Sitzung zu identifizieren, fragen Sie Metadatentabellen von `performance_schema` und `information_schema` im DB-Cluster ab.
Normalerweise weisen Datenbanken mit mäßiger bis erheblicher Last Warteereignisse auf. Die Warteereignisse sind möglicherweise akzeptabel, wenn die Leistung optimal ist. Wenn die Leistung nicht optimal ist, untersuchen Sie, wo die Datenbank die meiste Zeit verbringt. Schauen Sie sich die Warteereignisse an, die zur höchsten Belastung beitragen und finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.
**So suchen Sie SQL-Abfragen, die für hohe Last verantwortlich sind**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
1. Wählen Sie im Diagramm zur **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unten auf der Seite **Top-SQL** aus.
Das Diagramm listet die SQL-Abfragen auf, die für die Belastung verantwortlich sind. Diejenigen, die an der Spitze der Liste stehen, sind am meisten verantwortlich. Konzentrieren Sie sich auf diese Aussagen, um einen Engpass zu beheben.
Einen nützlichen Überblick über die Fehlerbehebung mit Performance Insights finden Sie im AWS Datenbank-Blogbeitrag [Analysieren von Amazon Aurora MySQL-Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Nach vergangenen Ereignissen suchen
Sie können einen Einblick in dieses Warteereignis erhalten, um nach früheren Vorkommen zu suchen. Führen Sie dazu die folgenden Aktionen aus:
+ Überprüfen Sie die Datenmanipulationssprache (DML) und den DDL-Durchsatz und die Latenz, um festzustellen, ob sich die Workload geändert hat.
Sie können Performance Insights verwenden, um Abfragen zu finden, die zum Zeitpunkt des Problems auf dieses Ereignis warten. Sie können auch den Digest der Abfragen anzeigen, die nahe dem Zeitpunkt des Problems ausgeführt werden.
+ Wenn Überwachungsprotokolle oder allgemeine Protokolle für den DB-Cluster aktiviert sind, können Sie nach allen Abfragen suchen, die für die Objekte (schema.table) ausgeführt werden, die an der Wartetransaktion beteiligt sind. Sie können auch nach den Abfragen suchen, die vor der Transaktion ausgeführt wurden.
Die Informationen, die zur Fehlerbehebung vergangener Ereignisse zur Verfügung stehen, sind begrenzt. Durch das Ausführen dieser Prüfungen wird nicht angezeigt, welches Objekt auf Informationen wartet. Sie können jedoch Tabellen mit hoher Last zum Zeitpunkt des Ereignisses und die Menge häufig operierter Zeilen identifizieren, die zum Zeitpunkt des Problems Konflikte verursachen. Sie können diese Informationen dann verwenden, um das Problem in einer Testumgebung zu reproduzieren und Einblicke in seine Ursache zu geben.
### Führen Sie Anfragen für Aurora MySQL Version 2 aus
In Aurora MySQL Version 2 können Sie die blockierte Sitzung direkt identifizieren, indem Sie `performance_schema`-Tabellen oder `sys`-Schemaansichten abfragen. Ein Beispiel kann veranschaulichen, wie Tabellen abfragen, um blockierende Abfragen und Sitzungen zu identifizieren.
In der folgenden Prozesslistenausgabe wartet die Verbindungs-ID `89` auf eine Metadatensperre und führt einen `TRUNCATE TABLE`-Befehl aus. In einer Abfrage der `performance_schema`-Tabellen oder `sys`-Schemaansichten zeigt die Ausgabe, dass die blockierende Sitzung `76` ist.
```
MySQL [(none)]> select @@version, @@aurora_version;
+-----------+------------------+
| @@version | @@aurora_version |
+-----------+------------------+
| 5.7.12 | 2.11.5 |
+-----------+------------------+
1 row in set (0.01 sec)
MySQL [(none)]> show processlist;
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL |
| 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL |
| 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL |
| 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL |
| 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL |
| 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL |
| 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL |
| 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL |
| 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL |
| 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL |
| 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL |
| 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL |
| 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL |
| 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist |
| 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) |
| 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
18 rows in set (0.00 sec)
```
Als Nächstes zeigt eine Abfrage der `performance_schema`-Tabellen oder `sys`-Schemaansichten, dass die blockierende Sitzung `76` ist.
```
MySQL [(none)]> select * from sys.schema_table_lock_waits;
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
1 row in set (0.00 sec)
```
### Antworten Sie auf die Blockiersitzung
Wenn Sie die Sitzung identifizieren, umfassen Ihre Optionen die Folgenden:
+ Wenden Sie sich an den Besitzer der Anwendung oder den Benutzer.
+ Wenn die Sperrsitzung im Leerlauf ist, erwägen Sie, die Sperrsitzung zu beenden. Diese Aktion könnte einen langen Rollback auslösen. Informationen zum Beenden einer Sitzung finden Sie unter [Beenden einer Sitzung oder Abfrage](mysql-stored-proc-ending.md).
Weitere Informationen zum Identifizieren blockierender Transaktionen finden Sie unter [Verwenden von InnoDB-Transaktions- und Sperrinformationen](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) in der MySQL-Dokumentation.
# synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex
Das `synch/mutex/innodb/aurora_lock_thread_slot_futex`-Ereignis tritt auf, wenn eine Sitzung eine Zeile für ein Update gesperrt hat und eine andere Sitzung versucht, dieselbe Zeile zu aktualisieren. Weitere Informationen finden Sie unter [InnoDB-Sperren](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) in der *MySQL-Referenz*.
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Version 2
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Mehrere DML-Anweisungen (Data Manipulation Language) greifen gleichzeitig auf dieselbe Zeile oder dieselben Zeilen zu.
## Aktionen
Abhängig von den anderen angezeigten Warteereignissen empfehlen wir unterschiedliche Aktionen.
**Topics**
+ [Finden und antworten Sie auf die SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind](#ams-waits.waitsynch.actions.id)
+ [Suchen und antworten Sie auf die Blockiersitzung](#ams-waits.waitsynch.actions.blocker)
### Finden und antworten Sie auf die SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind
Verwenden Sie Performance Insights, um die SQL-Anweisungen zu identifizieren, die für dieses Warteereignis verantwortlich sind. Berücksichtigen Sie dabei die folgenden Strategien:
+ Wenn Zeilensperren ein dauerhaftes Problem darstellen, erwägen Sie, die Anwendung neu zu schreiben, um eine optimistische Sperre zu verwenden.
+ Verwenden Sie mehrzeilige Anweisungen.
+ Verteilen Sie die Workload auf verschiedene Datenbankobjekte. Sie können dazu die Partitionierung verwenden.
+ Prüfen Sie den Wert des `innodb_lock_wait_timeout`-Parameters. Es steuert, wie lange Transaktionen warten, bevor ein Timeout-Fehler generiert wird.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag [Analysieren Sie Amazon Aurora MySQL Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Suchen und antworten Sie auf die Blockiersitzung
Stellen Sie fest, ob die Blockiersitzung im Leerlauf oder aktiv ist. Finden Sie außerdem heraus, ob die Sitzung von einer Anwendung oder einem aktiven Benutzer stammt.
Um die Sitzung zu identifizieren, die die Sperre hält, können Sie `SHOW ENGINE INNODB STATUS` ausführen. Das folgende Beispiel zeigt eine Beispielausgabe.
```
mysql> SHOW ENGINE INNODB STATUS;
---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
```
Oder Sie können die folgende Abfrage verwenden, um Details zu aktuellen Sperren zu extrahieren.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Wenn Sie die Sitzung identifizieren, umfassen Ihre Optionen die Folgenden:
+ Wenden Sie sich an den Besitzer der Anwendung oder den Benutzer.
+ Wenn die Sperrsitzung im Leerlauf ist, erwägen Sie, die Sperrsitzung zu beenden. Diese Aktion könnte einen langen Rollback auslösen. Informationen zum Beenden einer Sitzung finden Sie unter [Beenden einer Sitzung oder Abfrage](mysql-stored-proc-ending.md).
Weitere Informationen zum Identifizieren blockierender Transaktionen finden Sie unter [Verwenden von InnoDB-Transaktions- und Sperrinformationen](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) im *MySQL-Referenzhandbuch*.
# synch/mutex/innodb/buf\$1pool\$1mutex
Dieses `synch/mutex/innodb/buf_pool_mutex`-Ereignis tritt ein, wenn ein Thread eine Sperre des InnoDB-Puffer-Pools für den Zugriff auf eine Seite im Speicher erworben hat.
**Topics**
+ [Relevante Engine-Versionen](#ams-waits.bufpoolmutex.context.supported)
+ [Kontext](#ams-waits.bufpoolmutex.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.bufpoolmutex.causes)
+ [Aktionen](#ams-waits.bufpoolmutex.actions)
## Relevante Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Version 2
## Kontext
Der `buf_pool`-Mutex ist ein einzelner Mutex, der die Kontrolldatenstrukturen des Pufferpools schützt.
Weitere Informationen finden Sie unter [Überwachen von InnoDB-Mutex-Wartezeiten mithilfe des Leistungsschemas](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) in der MySQL-Dokumentation.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Dies ist ein Workload-spezifisches Warteereignis. Zu den häufigsten Ursachen für das Auftreten von `synch/mutex/innodb/buf_pool_mutex` unter den häufigsten Warteereignissen gehören die folgenden:
+ Die Pufferpoolgröße ist nicht groß genug, um den Arbeitsdatensatz zu speichern.
+ Die Workload ist für bestimmte Seiten einer bestimmten Tabelle in der Datenbank spezifischer, was zu Konflikten im Pufferpool führt.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen](#ams-waits.bufpoolmutex.actions.identify)
+ [Performance Insights verwenden](#ams-waits.bufpoolmutex.actions.action1)
+ [Erstellen eines Aurora-Replikats](#ams-waits.bufpoolmutex.actions.action2)
+ [Überprüfen Sie die Größe des Pufferpools](#ams-waits.bufpoolmutex.actions.action3)
+ [Überwachen Sie den globalen Statusverlauf](#ams-waits.bufpoolmutex.actions.action4)
### Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen
Normalerweise weisen Datenbanken mit mäßiger bis erheblicher Last Warteereignisse auf. Die Warteereignisse sind möglicherweise akzeptabel, wenn die Leistung optimal ist. Wenn die Leistung nicht optimal ist, untersuchen Sie, wo die Datenbank die meiste Zeit verbringt. Schauen Sie sich die Warteereignisse an, die zur höchsten Belastung beitragen und finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.
**So zeigen Sie das Top-SQL-Diagramm in der AWS-Managementkonsole an**
1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
1. Wählen Sie im Diagramm zur **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unter dem **Datenbankauslastungsdiagramm** die Option **Top-SQL** aus.
Das Diagramm listet die SQL-Abfragen auf, die für die Belastung verantwortlich sind. Diejenigen, die an der Spitze der Liste stehen, sind am meisten verantwortlich. Konzentrieren Sie sich auf diese Aussagen, um einen Engpass zu beheben.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag [Analysieren Sie Amazon Aurora MySQL Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Performance Insights verwenden
Dieses Ereignis hängt mit der Workload zusammen. Mit Performance Insights können Sie Folgendes tun:
+ Identifizieren Sie, wann Warteereignisse beginnen und ob sich die Workload zu dieser Zeit aus den Anwendungsprotokollen oder verwandten Quellen ändert.
+ Identifizieren Sie die SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind. Untersuchen Sie den Ausführungsplan der Abfragen, um sicherzustellen, dass diese Abfragen optimiert sind und geeignete Indizes verwenden.
Wenn die obersten Abfragen, die für das Warteereignis verantwortlich sind, sich auf dasselbe Datenbankobjekt oder dieselbe Tabelle beziehen, sollten Sie erwägen, dieses Objekt oder die Tabelle zu partitionieren.
### Erstellen eines Aurora-Replikats
Sie können Aurora-Replikationen erstellen, um schreibgeschützten Datenverkehr bereitzustellen. Sie können Aurora Auto Scaling auch verwenden, um Überspannungen im Leseverkehr zu behandeln. Stellen Sie sicher, dass geplante schreibgeschützte Aufgaben und logische Backups auf Aurora-Replikaten ausgeführt werden.
Weitere Informationen finden Sie unter [Amazon-Aurora-Auto-Scaling mit Aurora-Replikaten](Aurora.Integrating.AutoScaling.md).
### Überprüfen Sie die Größe des Pufferpools
Prüfen Sie anhand der Metrik `innodb_buffer_pool_wait_free`, ob die Pufferpoolgröße für die Workload ausreicht. Wenn der Wert dieser Metrik hoch ist und kontinuierlich zunimmt, deutet dies darauf hin, dass die Größe des Pufferpools nicht ausreicht, um die Workload zu bewältigen. Wenn `innodb_buffer_pool_size` richtig eingestellt wurde, sollte der Wert von `innodb_buffer_pool_wait_free` klein sein. Weitere Informationen finden Sie unter [Innodb\$1buffer\$1pool\$1wait\$1free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free) in der MySQL-Dokumentation.
Erhöhen Sie die Pufferpool-Größe, wenn die DB-Instance über genügend Speicher für Sitzungspuffer und Betriebssystemaufgaben verfügt. Wenn dies nicht der Fall ist, ändern Sie die DB-Instance in eine größere DB-Instance-Klasse, um zusätzlichen Speicher zu erhalten, der dem Pufferpool zugewiesen werden kann.
**Anmerkung**
Aurora MySQL passt den Wert von `innodb_buffer_pool_instances` automatisch basierend auf der konfigurierten `innodb_buffer_pool_size` an.
### Überwachen Sie den globalen Statusverlauf
Durch die Überwachung der Änderungsraten von Statusvariablen können Sie Sperr- oder Speicherprobleme auf Ihrer DB-Instance erkennen. Aktivieren Sie den globalen Statusverlauf (GoSH), wenn er noch nicht aktiviert ist. Weitere Informationen zu GoSH finden Sie unter [Verwalten des globalen Statusverlaufs](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
Sie können auch benutzerdefinierte Amazon-CloudWatch-Metriken erstellen, um Statusvariablen zu überwachen. Weitere Informationen finden Sie unter [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).
# synch/mutex/innodb/fil\$1system\$1mutex
Dieses `synch/mutex/innodb/fil_system_mutex`-Ereignis tritt auf, wenn eine Sitzung darauf wartet, auf den Tablespace-Speichercache zuzugreifen.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Kontext](#ams-waits.innodb-fil-system-mutex.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.innodb-fil-system-mutex.causes)
+ [Aktionen](#ams-waits.innodb-fil-system-mutex.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Versionen 2 und 3
## Kontext
InnoDB verwendet Tablespaces, um den Speicherbereich für Tabellen und Protokolldateien zu verwalten. Der *Tablespace-Speichercache* ist eine globale Speicherstruktur, die Informationen über Tablespaces verwaltet. MySQL verwendet `synch/mutex/innodb/fil_system_mutex` Wartezeiten, um den gleichzeitigen Zugriff auf den Tablespace-Speichercache zu steuern.
Das Ereignis `synch/mutex/innodb/fil_system_mutex` zeigt an, dass derzeit mehr als eine Operation vorhanden ist, die Informationen im Tabellenbereichsspeichercache für denselben Tabellenbereich abrufen und bearbeiten muss.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `synch/mutex/innodb/fil_system_mutex`-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, tritt dies normalerweise auf, wenn alle der folgenden Bedingungen vorliegen:
+ Eine Zunahme der gleichzeitigen DML-Vorgänge (Data Manipulation Language), die Daten in derselben Tabelle aktualisieren oder löschen.
+ Der Tablespace für diese Tabelle ist sehr groß und hat viele Datenseiten.
+ Der Füllfaktor für diese Datenseiten ist niedrig.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [Reorganisieren Sie große Tabellen außerhalb der Hauptverkehrszeiten](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen
Normalerweise weisen Datenbanken mit mäßiger bis erheblicher Last Warteereignisse auf. Die Warteereignisse sind möglicherweise akzeptabel, wenn die Leistung optimal ist. Wenn die Leistung nicht optimal ist, untersuchen Sie, wo die Datenbank die meiste Zeit verbringt. Schauen Sie sich die Warteereignisse an, die zur höchsten Belastung beitragen und finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.
**So suchen Sie SQL-Abfragen, die für hohe Last verantwortlich sind**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
1. Wählen Sie im Diagramm zur **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unten auf der Seite **Top-SQL** aus.
Das Diagramm listet die SQL-Abfragen auf, die für die Belastung verantwortlich sind. Diejenigen, die an der Spitze der Liste stehen, sind am meisten verantwortlich. Konzentrieren Sie sich auf diese Aussagen, um einen Engpass zu beheben.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag [Analysieren Sie Amazon Aurora MySQL Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
Eine andere Möglichkeit herauszufinden, welche Abfragen eine hohe Anzahl von `synch/mutex/innodb/fil_system_mutex`-Wartezeiten verursachen, besteht darin, `performance_schema` zu überprüfen, wie im folgenden Beispiel.
```
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
THREAD_ID: 19
EVENT_ID: 195057
END_EVENT_ID: 195057
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:6700
TIMER_START: 1010146190118400
TIMER_END: 1010146196524000
TIMER_WAIT: 6405600
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 2. row ***************************
THREAD_ID: 23
EVENT_ID: 5480
END_EVENT_ID: 5480
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:5906
TIMER_START: 995269979908800
TIMER_END: 995269980159200
TIMER_WAIT: 250400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 3. row ***************************
THREAD_ID: 55
EVENT_ID: 23233794
END_EVENT_ID: NULL
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:449
TIMER_START: 1010492125341600
TIMER_END: 1010494304900000
TIMER_WAIT: 2179558400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: 23233786
NESTING_EVENT_TYPE: WAIT
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
```
### Reorganisieren Sie große Tabellen außerhalb der Hauptverkehrszeiten
Reorganisieren Sie große Tabellen, die Sie während eines Wartungsfensters außerhalb der Produktionszeiten als Quelle einer großen Anzahl von `synch/mutex/innodb/fil_system_mutex`-Warteereignissen identifizieren. Dadurch wird sichergestellt, dass die Bereinigung der internen Tablespaces-Zuordnung nicht erfolgt, wenn der schnelle Zugriff auf die Tabelle kritisch ist. Informationen zum Reorganisieren von Tabellen finden Sie unter [OPTIMIZE TABLE-Anweisung](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html) in der *MySQL-Referenz*.
# synch/mutex/innodb/trx\$1sys\$1mutex
Dieses `synch/mutex/innodb/trx_sys_mutex`-Ereignis tritt auf, wenn eine hohe Datenbankaktivität mit einer großen Anzahl von Transaktionen besteht.
**Topics**
+ [Relevante Engine-Versionen](#ams-waits.trxsysmutex.context.supported)
+ [Kontext](#ams-waits.trxsysmutex.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.trxsysmutex.causes)
+ [Aktionen](#ams-waits.trxsysmutex.actions)
## Relevante Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Versionen 2 und 3
## Kontext
Intern verwendet das InnoDB-Datenbankmodul die wiederholbare Lese-Isolationsstufe mit Snapshots, um Lesekonsistenz zu gewährleisten. Dies gibt Ihnen eine zeitpunktbezogene Ansicht der Datenbank zum Zeitpunkt der Erstellung des Snapshots.
In InnoDB werden alle Änderungen auf die Datenbank angewendet, sobald sie eintreffen, unabhängig davon, ob sie festgeschrieben wurden. Dieser Ansatz bedeutet, dass ohne Multiversions-Parallelitätssteuerung (MVCC) alle mit der Datenbank verbundenen Benutzer alle Änderungen und die neuesten Zeilen sehen. Daher benötigt InnoDB eine Möglichkeit, die Änderungen zu verfolgen, um zu verstehen, was bei Bedarf zurückgesetzt werden soll.
Dazu verwendet InnoDB ein Transaktionssystem (`trx_sys`) zum Verfolgen von Snapshots. Das Transaktionssystem führt folgenden Aktionen:
+ Verfolgt die Transaktions-ID für jede Zeile in den Rückgängig-Protokollen.
+ Verwendet eine interne InnoDB-Struktur namens `ReadView`, die hilft zu identifizieren, welche Transaktions-IDs für einen Snapshot sichtbar sind.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Jede Datenbankoperation, die eine konsistente und kontrollierte Behandlung (Erstellen, Lesen, Aktualisieren und Löschen) von Transaktions-IDs erfordert, erzeugt einen Aufruf von `trx_sys` an den Mutex.
Diese Aufrufe erfolgen innerhalb von drei Funktionen:
+ `trx_sys_mutex_enter` – Erzeugt den Mutex.
+ `trx_sys_mutex_exit` – Gibt den Mutex frei.
+ `trx_sys_mutex_own` – Testet, ob der Mutex im Besitz ist.
Die Instrumentierung des InnoDB-Leistungsschemas verfolgt alle `trx_sys`-Mutex-Aufrufe. Die Verfolgung umfasst unter anderem die Verwaltung von `trx_sys` beim Starten oder Herunterfahren der Datenbank, Rollback-Vorgänge, das Rückgängigmachen von Bereinigungen, den Zeilenlesezugriff und das Laden von Pufferpools. Eine hohe Datenbankaktivität mit einer großen Anzahl von Transaktionen führt dazu, dass `synch/mutex/innodb/trx_sys_mutex` unter den Top-Warteereignissen erscheint.
Weitere Informationen finden Sie unter [Überwachen von InnoDB-Mutex-Wartezeiten mithilfe des Leistungsschemas](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) in der MySQL-Dokumentation.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen](#ams-waits.trxsysmutex.actions.identify)
+ [Untersuchen Sie andere Warteereignisse](#ams-waits.trxsysmutex.actions.action1)
### Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen
Normalerweise weisen Datenbanken mit mäßiger bis erheblicher Last Warteereignisse auf. Die Warteereignisse sind möglicherweise akzeptabel, wenn die Leistung optimal ist. Wenn die Leistung nicht optimal ist, untersuchen Sie, wo die Datenbank die meiste Zeit verbringt. Schauen Sie sich die Warteereignisse an, die zur höchsten Belastung beitragen. Finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.
**So zeigen Sie das Top-SQL-Diagramm in AWS-Managementkonsole an**
1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
1. Wählen Sie im Diagramm zur **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unter dem **Datenbankauslastungsdiagramm** die Option **Top-SQL** aus.
Das Diagramm listet die SQL-Abfragen auf, die für die Belastung verantwortlich sind. Diejenigen, die an der Spitze der Liste stehen, sind am meisten verantwortlich. Konzentrieren Sie sich auf diese Aussagen, um einen Engpass zu beheben.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag [Analysieren Sie Amazon Aurora MySQL Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Untersuchen Sie andere Warteereignisse
Untersuchen Sie die anderen Warteereignisse, die dem `synch/mutex/innodb/trx_sys_mutex`-Warteereignis zugeordnet sind. Auf diese Weise finden Sie weitere Informationen über die Art der Workload. Eine große Anzahl von Transaktionen kann den Durchsatz verringern, die Workload kann dies jedoch auch erforderlich machen.
Weitere Informationen zum Optimieren von Transaktionen finden Sie unter [Optimieren der InnoDB-Transaktionsverwaltung](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) in der MySQL-Dokumentation.
# synch/sxlock/innodb/hash\$1table\$1locks
Das `synch/sxlock/innodb/hash_table_locks`-Ereignis tritt ein, wenn Seiten, die nicht im Pufferpool gefunden wurden, aus dem Speicher gelesen werden müssen.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Kontext](#ams-waits.sx-lock-hash-table-locks.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.sx-lock-hash-table-locks.causes)
+ [Aktionen](#ams-waits.sx-lock-hash-table-locks.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Versionen unterstützt:
+ Aurora-MySQL-Versionen 2 und 3
## Kontext
Das Ereignis `synch/sxlock/innodb/hash_table_locks` zeigt an, dass ein Workload häufig auf Daten zugreift, die nicht im Pufferpool gespeichert sind. Dieses Warteereignis ist mit neuen Seitenhinzufügungen und alten Datenräumungen aus dem Pufferpool verbunden. Die im Pufferpool gespeicherten Daten und neuen Daten müssen zwischengespeichert werden, sodass die gealterten Seiten geräumt werden, um das Zwischenspeichern der neuen Seiten zu ermöglichen. MySQL verwendet einen am wenigsten verwendeten (LRU) -Algorithmus, um Seiten aus dem Puffer-Pool zu entfernen. Die Workload versucht, auf Daten zuzugreifen, die nicht in den Pufferpool geladen wurden, oder auf Daten, die aus dem Pufferpool vertrieben wurden.
Dieses Warteereignis tritt auf, wenn der Workload auf die Daten in Dateien auf der Festplatte zugreifen muss oder wenn Blöcke von der LRU-Liste des Pufferpools befreit oder zur LRU-Liste des Pufferpools hinzugefügt werden. Diese Vorgänge warten darauf, eine gemeinsame ausgeschlossene Sperre (SX-Lock) zu erhalten. Diese SX-Sperre wird für die Synchronisation über die *Hash-Tabelle* verwendet, bei der es sich um eine Tabelle im Speicher handelt, die die Leistung des Pufferpoolzugriffs verbessern soll.
Weitere Informationen finden Sie unter [Bufferpool](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html) in der MySQL-Dokumentation.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `synch/sxlock/innodb/hash_table_locks`-Warteereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
**Ein unterdimensionierter Pufferpool**
Die Größe des Pufferpools ist zu klein, um alle häufig aufgerufenen Seiten im Speicher zu behalten.
**Starke Workload**
Die Workload verursacht häufige Bereinigungen und das Neuladen von Datenseiten in den Puffercache.
**Fehler beim Lesen der Seiten**
Es gibt Fehler beim Lesen von Seiten im Pufferpool, die auf eine Beschädigung von Daten hinweisen können.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Erhöhen Sie die Größe des Pufferpools](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [Verbesserung der Datenzugriffsmuster](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [Reduzieren oder vermeiden Sie vollständige Tabellen-Scans](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [Überprüfen Sie die Fehlerprotokolle auf Seitenbeschädigung](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)
### Erhöhen Sie die Größe des Pufferpools
Stellen Sie sicher, dass diese Pufferpools für die Workload entsprechend dimensioniert sind. Sie können dazu die Trefferrate des Pufferpools überprüfen. Wenn der Wert unter 95 Prozent sinkt, sollten Sie in der Regel die Größe des Pufferpools erhöhen. Ein größerer Pufferpool kann häufig aufgerufene Seiten länger im Speicher halten. Um die Größe des Pufferpools zu vergrößern, ändern Sie den Wert des `innodb_buffer_pool_size`-Parameters. Der Standardwert dieses Parameters basiert auf der DB-Instance-Klassengröße. Weitere Informationen finden Sie unter [bewährte Methoden für die Amazon-Aurora-MySQL-Datenbankkonfiguration](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/).
### Verbesserung der Datenzugriffsmuster
Überprüfen Sie die von dieser Wartezeit betroffenen Abfragen und deren Ausführungspläne. Erwägen Sie, die Datenzugriffsmuster zu verbessern. Wenn Sie beispielsweise [mysqli\$1result:: fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php) verwenden können Sie versuchen, die Abrufgröße des Arrays zu erhöhen.
Sie können Performance Insights verwenden, um Abfragen und Sitzungen anzuzeigen, die möglicherweise ein `synch/sxlock/innodb/hash_table_locks`-Warteereignis verursachen.
**So suchen Sie SQL-Abfragen, die für hohe Last verantwortlich sind**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
1. Wählen Sie im Diagramm zur **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unten auf der Seite **Top-SQL** aus.
Das Diagramm listet die SQL-Abfragen auf, die für die Belastung verantwortlich sind. Diejenigen, die an der Spitze der Liste stehen, sind am meisten verantwortlich. Konzentrieren Sie sich auf diese Aussagen, um einen Engpass zu beheben.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im AWS-Database Blog-Beitrag [Analysieren von Amazon-Aurora-MySQL-Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Reduzieren oder vermeiden Sie vollständige Tabellen-Scans
Überwachen Sie Ihre Workload, um zu sehen, ob vollständige Tabellen-Scans ausgeführt werden, und wenn dies der Fall ist, reduzieren oder vermeiden Sie sie. Sie können beispielsweise Statusvariablen wie `Handler_read_rnd_next` überwachen. Weitere Informationen finden Sie unter [Server-Status-Variablen](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next) in der MySQL-Dokumentation.
### Überprüfen Sie die Fehlerprotokolle auf Seitenbeschädigung
Sie können mysql-error.log auf korruptionsbezogene Nachrichten überprüfen, die zum Zeitpunkt des Problems erkannt wurden. Nachrichten, mit denen Sie arbeiten können, um das Problem zu beheben, befinden sich im Fehlerprotokoll. Möglicherweise müssen Sie Objekte neu erstellen, die als beschädigt gemeldet wurden.
# synch/mutex/innodb/temp\$1poolmanager\$1mutex
Das `synch/mutex/innodb/temp_pool_manager_mutex` Wait-Ereignis tritt ein, wenn eine Sitzung darauf wartet, einen Mutex für die Verwaltung des Pools temporärer Sitzungs-Tablespaces zu erhalten.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.io-temppoolmanager.context.supported)
+ [Kontext](#ams-waits.io-temppoolmanager.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.io-temppoolmanager.causes)
+ [Aktionen](#ams-waits.io-temppoolmanager.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Version 3
## Kontext
Aurora MySQL Version 3.x und höher steuert mehrere Sitzungen`temp_pool_manager_mutex`, die gleichzeitig auf den temporären Tablespace-Pool zugreifen. Aurora MySQL verwaltet Speicher über ein Aurora-Cluster-Volume für persistente Daten und lokalen Speicher für temporäre Dateien. Ein temporärer Tablespace wird benötigt, wenn eine Sitzung eine temporäre Tabelle auf dem Aurora-Cluster-Volume erstellt.
Wenn eine Sitzung zum ersten Mal einen temporären Tablespace anfordert, weist MySQL temporäre Sitzungs-Tablespaces aus dem Shared Pool zu. Eine Sitzung kann bis zu 2 temporäre Tablespaces gleichzeitig für die folgenden Tabellentypen enthalten:
+ Vom Benutzer erstellte temporäre Tabellen
+ Von Optimizer generierte interne temporäre Tabellen
Die `TempTable` Standard-Engine verwendet den folgenden Überlaufmechanismus, um temporäre Tabellen zu verarbeiten:
+ Speichert Tabellen im RAM bis zum [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram)Limit.
+ Wechselt zu Dateien im lokalen Speicher, die dem Arbeitsspeicher zugeordnet sind, wenn der Arbeitsspeicher voll ist.
+ Verwendet das gemeinsam genutzte Cluster-Volume, wenn die Speicherzuordnungsdateien ihr Limit erreichen. [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap)
Wenn temporäre Tabellen sowohl die RAM- als auch die lokalen Speichergrenzen überschreiten, verwaltet MySQL sie mithilfe von Tablespace auf der Festplatte.
Wenn für eine Sitzung eine temporäre Tabelle auf der Festplatte erforderlich ist, kann MySQL:
+ Sucht nach verfügbaren `INACTIVE` Tablespaces im Pool, die wiederverwendet werden können.
+ Erzeugt 10 neue Tablespaces, wenn keine Leerzeichen vorhanden sind. `INACTIVE`
Wenn eine Sitzung unterbrochen wird, geht MySQL wie folgt vor:
+ Kürzt die temporären Tablespaces der Sitzung.
+ Markiert sie im Pool zur Wiederverwendung als INAKTIV.
+ Behält die aktuelle Poolgröße bis zum Neustart des Servers bei.
+ Kehrt nach dem Neustart zur Standard-Poolgröße (10 Tablespaces) zurück.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Häufige Situationen, die dieses Warteereignis verursachen:
+ Gleichzeitige Sitzungen, die interne temporäre Tabellen auf dem Cluster-Volume erstellen.
+ Gleichzeitige Sitzungen, in denen temporäre Benutzertabellen auf dem Cluster-Volume erstellt werden.
+ Plötzliches Beenden von Sitzungen, die aktive Tablespaces verwenden.
+ Erweiterung des Tablespace-Pools bei hohen Schreiblasten.
+ Gleichzeitige Abfragen, auf die zugegriffen wird `INFORMATION_SCHEMA.`
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Überwachen und optimieren Sie die Nutzung temporärer Tabellen](#ams-waits.io-temppoolmanager.actions.monitor)
+ [Überprüfen Sie Abfragen mit INFORMATION\$1SCHEMA](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [Erhöhen Sie den Parameter innodb\$1sync\$1array\$1size](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [Verbindungspooling implementieren](#ams-waits.io-temppoolmanager.actions.connection_pooling)
### Überwachen und optimieren Sie die Nutzung temporärer Tabellen
Verwenden Sie eine der folgenden Methoden, um die Nutzung temporärer Tabellen zu überwachen und zu optimieren:
+ Überprüfen Sie den `Created_tmp_disk_tables` Zähler in Performance Insights, um die Erstellung temporärer Tabellen auf der Festplatte in Ihrem Aurora-Cluster nachzuverfolgen.
+ Führen Sie diesen Befehl in Ihrer Datenbank aus, um die Erstellung temporärer Tabellen direkt zu überwachen:`mysql> show status like '%created_tmp_disk%'`.
**Anmerkung**
Das Verhalten temporärer Tabellen unterscheidet sich zwischen Aurora MySQL-Reader-Knoten und Writer-Knoten. Weitere Informationen finden Sie unter [Neues temporäres Tabellenverhalten in Aurora-MySQL-Version 3](ams3-temptable-behavior.md).
Nachdem Sie Abfragen identifiziert haben, die temporäre Tabellen erstellen, führen Sie die folgenden Optimierungsschritte durch:
+ Wird verwendet`EXPLAIN`, um Ausführungspläne für Abfragen zu untersuchen und zu ermitteln, wo und warum temporäre Tabellen erstellt werden.
+ Ändern Sie Abfragen, um die Verwendung temporärer Tabellen nach Möglichkeit zu reduzieren.
Wenn Leistungsprobleme durch Abfrageoptimierung allein nicht behoben werden können, sollten Sie die folgenden Konfigurationsparameter anpassen:
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram)- Steuert die maximale RAM-Auslastung für temporäre Tabellen.
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap)- Legt das Limit für die Speicherung von Dateien mit Speicherabbildung fest.
+ [https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size)- Gilt, wenn `aurora_tmptable_enable_per_table_limit` aktiviert (standardmäßig deaktiviert).
**Wichtig**
Beachten Sie, dass für bestimmte Abfragebedingungen immer temporäre Tabellen auf der Festplatte erforderlich sind, unabhängig von den Konfigurationseinstellungen. Weitere Informationen zur `TempTable` Speicher-Engine finden Sie unter [Verwenden der TempTable Speicher-Engine auf Amazon RDS for MySQL und Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
### Überprüfen Sie Abfragen mit INFORMATION\$1SCHEMA
Wenn Sie `INFORMATION_SCHEMA` Tabellen abfragen, erstellt MySQL temporäre InnoDB-Tabellen auf dem Cluster-Volume. Jede Sitzung benötigt einen temporären Tablespace für diese Tabellen, was bei vielen gleichzeitigen Zugriffen zu Leistungseinbußen führen kann.
Um die Leistung zu verbessern:
+ Verwenden Sie `PERFORMANCE_SCHEMA` statt `INFORMATION_SCHEMA` wo möglich.
+ Wenn Sie diese Abfragen verwenden müssen`INFORMATION_SCHEMA`, reduzieren Sie die Häufigkeit, mit der Sie diese Abfragen ausführen.
### Erhöhen Sie den Parameter innodb\$1sync\$1array\$1size
Der `innodb_sync_array_size` Parameter steuert die Größe des mutex/lock Warte-Arrays in MySQL. Der Standardwert von `1` funktioniert für allgemeine Workloads, aber wenn Sie ihn erhöhen, können Thread-Konflikte bei hoher Parallelität reduziert werden.
Wenn Ihre Arbeitslast eine zunehmende Anzahl wartender Threads aufweist:
+ Überwachen Sie die Anzahl der wartenden Threads in Ihrem Workload.
+ Legen Sie den `innodb_sync_array_size` Wert gleich oder höher als die vCPU-Anzahl Ihrer Instance fest, um die Thread-Koordinationsstruktur aufzuteilen und Konflikte zu reduzieren.
**Anmerkung**
Informationen zur Anzahl der auf Ihrer RDS-Instance CPUs verfügbaren v finden Sie in den vCPU-Spezifikationen unter [Amazon RDS-Instance-Typen](https://aws.amazon.com/rds/instance-types/).
### Verbindungspooling implementieren
MySQL weist jeder Sitzung, die eine temporäre Tabelle erstellt, einen eigenen Tablespace zu. Dieser Tablespace bleibt aktiv, bis die Datenbankverbindung beendet wird. Gehen Sie wie folgt vor, um Ihre Ressourcen effizienter zu verwalten:
+ Implementieren Sie Verbindungspooling, um die Anzahl der aktiven temporären Tablespaces zu begrenzen.
+ Verwenden Sie bestehende Verbindungen wieder, anstatt für jeden Vorgang neue zu erstellen.
# Optimierung von Aurora MySQL mit Thread-Status
In der folgenden Tabelle werden die häufigsten allgemeinen Thread-Zustände für Aurora MySQL zusammengefasst.
| Allgemeiner Thread-Zustand | Beschreibung |
| --- | --- |
| [Erstellen des Sortierindex](ams-states.sort-index.md) | Dieser Thread-Zustand zeigt an, dass ein Thread eine `SELECT`-Anweisung verarbeitet, die die Verwendung einer internen temporären Tabelle zum Sortieren der Daten erfordert. |
| [Senden von Daten](ams-states.sending-data.md) | Dieser Thread-Zustand zeigt an, dass ein Thread Zeilen für eine Abfrage liest und filtert, um die richtige Ergebnismenge zu ermitteln. |
# Erstellen des Sortierindex
Dieser `creating sort index`-Thread-Zustand zeigt an, dass ein Thread eine `SELECT`-Anweisung verarbeitet, die die Verwendung einer internen temporären Tabelle zum Sortieren der Daten erfordert.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-states.sort-index.context.supported)
+ [Kontext](#ams-states.sort-index.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-states.sort-index.causes)
+ [Aktionen](#ams-states.sort-index.actions)
## Unterstützte Engine-Versionen
Diese Thread-Statusinformationen werden für die folgenden Versionen unterstützt:
+ Aurora MySQL Version 2 bis 2.09.2
## Kontext
Der Zustand `creating sort index` wird angezeigt, wenn eine Abfrage mit einer `ORDER BY`- oder `GROUP BY`-Klausel keinen vorhandenen Index verwenden kann, um die Operation auszuführen. In diesem Fall muss MySQL eine teurere `filesort`-Operation ausführen. Dieser Vorgang wird normalerweise im Speicher ausgeführt, wenn die Ergebnismenge nicht zu groß ist. Andernfalls geht es darum, eine Datei auf der Festplatte zu erstellen.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Das Auftreten von `creating sort index` deutet nicht allein auf ein Problem hin. Wenn die Leistung schlecht ist und Sie häufig `creating sort index`-Instances sehen, sind die wahrscheinlichste Ursache langsame Abfragen mit `ORDER BY`- oder `GROUP BY`-Operatoren.
## Aktionen
Die allgemeine Richtlinie besteht darin, Abfragen mit `ORDER BY`- oder `GROUP BY`-Klauseln zu finden, die mit den Erhöhungen des Zustands `creating sort index` verbunden sind. Prüfen Sie dann, ob das Hinzufügen eines Index oder das Vergrößern der Sortierpuffergröße das Problem löst.
**Topics**
+ [Schalten Sie das Leistungsschema ein, wenn es nicht aktiviert ist](#ams-states.sort-index.actions.enable-pfs)
+ [Identifizieren Sie die Problemanfragen](#ams-states.sort-index.actions.identify)
+ [Untersuchen Sie die Erklärungspläne für die Dateisortierungs-Nutzung](#ams-states.sort-index.actions.plan)
+ [Erhöhen Sie die Sortierpuffergröße](#ams-states.sort-index.actions.increasebuffersize)
### Schalten Sie das Leistungsschema ein, wenn es nicht aktiviert ist
Performance Insights meldet Thread-Status nur, wenn Leistungsschema-Instrumente nicht aktiviert sind. Wenn Leistungsschema-Instrumente aktiviert sind, meldet Performance Insights stattdessen Warteereignisse. Leistungsschema-Instrumente bieten zusätzliche Erkenntnisse und bessere Tools, wenn Sie potenzielle Leistungsprobleme untersuchen. Daher wird empfohlen, dass Sie das Leistungsschema aktivieren. Weitere Informationen finden Sie unter [Übersicht über das Leistungsschema für Performance Insights auf Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
### Identifizieren Sie die Problemanfragen
KennUm aktuelle Abfragen zu identifizieren, die eine Erhöhung des `creating sort index`-Zustands verursachen, führen Sie `show processlist` aus und prüfen Sie, ob eine der Abfragen `ORDER BY` oder `GROUP BY` hat. Führen Sie optional `explain for connection N` aus, wobei `N` die Prozesslisten-ID der Abfrage mit `filesort` ist.
Um frühere Abfragen zu identifizieren, die diese Zunahmen verursachen, aktivieren Sie das Protokoll für langsame Abfragen und suchen Sie die Abfragen mit `ORDER BY`. Führen Sie `EXPLAIN` für die langsamen Abfragen aus und suchen Sie nach „using filesort“. Weitere Informationen finden Sie unter [Untersuchen Sie die Erklärungspläne für die Dateisortierungs-Nutzung](#ams-states.sort-index.actions.plan).
### Untersuchen Sie die Erklärungspläne für die Dateisortierungs-Nutzung
Identifizieren Sie die Anweisungen mit `ORDER BY`- oder `GROUP BY`-Klauseln, die den `creating sort index`-Zustand ergeben.
Das folgende Beispiel zeigt, wie `explain` für eine Abfrage ausgeführt wird. Die Spalte `Extra` zeigt, dass diese Abfrage `filesort` verwendet.
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2064548
filtered: 100.00
Extra: Using filesort
1 row in set, 1 warning (0.01 sec)
```
Das folgende Beispiel zeigt das Ergebnis der Ausführung von `EXPLAIN` für dieselbe Abfrage, nachdem ein Index für Spalte `c1` erstellt wurde.
```
mysql> alter table mytable add index (c1);
```
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: index
possible_keys: NULL
key: c1
key_len: 1023
ref: NULL
rows: 10
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.01 sec)
```
Informationen zur Verwendung von Indizes zur Optimierung der Sortierreihenfolge finden Sie unter [ORDER BY-Optimierung](https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html) in der MySQL-Dokumentation.
### Erhöhen Sie die Sortierpuffergröße
Um festzustellen, ob für eine bestimmte Abfrage ein `filesort`-Prozess erforderlich ist, der eine Datei auf dem Datenträger erstellt hat, überprüfen Sie den `sort_merge_passes`-Variablenwert, nachdem Sie die Abfrage ausgeführt haben. Es folgt ein Beispiel.
```
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
--- run query
mysql> select * from mytable order by u limit 10;
--- run status again:
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
```
Wenn der Wert von `sort_merge_passes` hoch ist, sollten Sie die Größe des Sortierpuffers erhöhen. Wenden Sie den Anstieg auf Sitzungsebene an, da eine globale Erhöhung der RAM-MySQL-Nutzung erheblich erhöhen kann. Das folgende Beispiel zeigt, wie Sie die Größe des Sortierpuffers ändern, bevor Sie eine Abfrage ausführen.
```
mysql> set session sort_buffer_size=10*1024*1024;
Query OK, 0 rows affected (0.00 sec)
-- run query
```
# Senden von Daten
Dieser `sending data`-Thread-Zustand zeigt an, dass ein Thread Zeilen für eine Abfrage liest und filtert, um die richtige Ergebnismenge zu ermitteln. Der Name ist irreführend, da er andeutet, dass der Zustand Daten überträgt, nicht sammelt und vorbereitet, um später gesendet zu werden.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-states.sending-data.context.supported)
+ [Kontext](#ams-states.sending-data.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-states.sending-data.causes)
+ [Aktionen](#ams-states.sending-data.actions)
## Unterstützte Engine-Versionen
Diese Thread-Statusinformationen werden für die folgenden Versionen unterstützt:
+ Aurora MySQL Version 2 bis 2.09.2
## Kontext
Viele Thread-Zustände sind kurzlebig. Operationen, die während `sending data` auftreten, führen in der Regel eine große Anzahl von Platten- oder Cache-Lesevorgängen durch. Daher ist `sending data` häufig der am längsten ausgeführte Zustand während der Lebensdauer einer bestimmten Abfrage. Dieser Status wird angezeigt, wenn Aurora MySQL Folgendes tut:
+ Lesen und Verarbeiten von Zeilen für eine `SELECT`-Anweisung
+ Durchführen einer großen Anzahl von Lesevorgängen von der Festplatte oder vom Speicher
+ Vollständiges Lesen aller Daten aus einer bestimmten Abfrage durchführen
+ Lesen von Daten aus einer Tabelle, einem Index oder der Arbeit einer gespeicherten Prozedur
+ Daten sortieren, gruppieren oder bestellen
Nachdem der `sending data`-Zustand die Vorbereitung der Daten abgeschlossen hat, zeigt der Thread-Zustand `writing to net` die Rückgabe der Daten an den Client an. Normalerweise wird `writing to net` nur erfasst, wenn die Ergebnismenge sehr groß ist oder eine starke Netzwerklatenz die Übertragung verlangsamt.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Das Auftreten von `sending data` deutet nicht allein auf ein Problem hin. Wenn die Leistung schlecht ist und Sie häufige Instances von `sending data` sehen, sind die wahrscheinlichsten Ursachen wie folgt.
**Topics**
+ [Ineffiziente Abfrage](#ams-states.sending-data.causes.structure)
+ [Suboptimale Serverkonfiguration](#ams-states.sending-data.causes.server)
### Ineffiziente Abfrage
In den meisten Fällen ist für diesen Status eine Abfrage verantwortlich, die keinen geeigneten Index verwendet, um die Ergebnismenge einer bestimmten Abfrage zu finden. Betrachten Sie beispielsweise eine Abfrage, die eine 10-Millionen-Datensatztabelle für alle Bestellungen in Kalifornien liest, wobei die Bundesstaatsspalte nicht indiziert oder schlecht indiziert ist. Im letzteren Fall könnte der Index existieren, aber der Optimierer ignoriert ihn aufgrund der geringen Kardinalität.
### Suboptimale Serverkonfiguration
Wenn im Zustand `sending data` mehrere Abfragen erscheinen, ist der Datenbankserver möglicherweise schlecht konfiguriert. Insbesondere könnte der Server die folgenden Probleme haben:
+ Der Datenbankserver verfügt nicht über genügend Rechenkapazität: Festplatten-I/O, Festplattentyp und -geschwindigkeit, CPU oder Anzahl von CPUs.
+ Dem Server mangelt es an zugewiesenen Ressourcen, wie dem InnoDB-Pufferpool für InnoDB-Tabellen oder dem Schlüsselpuffer für Tabellen. MyIsam
+ Arbeitsspeichereinstellungen pro Thread wie `sort_buffer`, `read_buffer` und `join_buffer` verbrauchen mehr RAM als erforderlich, wodurch der physische Server an Speicherressourcen mangelt.
## Aktionen
Die allgemeine Richtlinie besteht darin, Abfragen zu finden, die eine große Anzahl von Zeilen zurückgeben, indem Sie das Leistungsschema überprüfen. Wenn die Protokollierung von Abfragen aktiviert ist, die keine Indizes verwenden, können Sie auch die Ergebnisse der langsamen Protokolle untersuchen.
**Topics**
+ [Schalten Sie das Leistungsschema ein, wenn es nicht aktiviert ist](#ams-states.sending-data.actions.enable-pfs)
+ [Prüfen Sie die Speichereinstellungen](#ams-states.sending-data.actions.memory)
+ [Untersuchen Sie die Erklärungspläne zur Indexverwendung](#ams-states.sending-data.actions.plans)
+ [Überprüfen Sie das Volume der zurückgegebenen Daten](#ams-states.sending-data.actions.maintenance)
+ [Auf Parallelitätsprobleme prüfen](#ams-states.sending-data.actions.concurrent-queries)
+ [Überprüfen der Struktur Ihrer Abfrage](#ams-states.sending-data.actions.subqueries)
### Schalten Sie das Leistungsschema ein, wenn es nicht aktiviert ist
Performance Insights meldet Thread-Status nur, wenn Leistungsschema-Instrumente nicht aktiviert sind. Wenn Leistungsschema-Instrumente aktiviert sind, meldet Performance Insights stattdessen Warteereignisse. Leistungsschema-Instrumente bieten zusätzliche Erkenntnisse und bessere Tools, wenn Sie potenzielle Leistungsprobleme untersuchen. Daher wird empfohlen, dass Sie das Leistungsschema aktivieren. Weitere Informationen finden Sie unter [Übersicht über das Leistungsschema für Performance Insights auf Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
### Prüfen Sie die Speichereinstellungen
Untersuchen Sie die Speichereinstellungen für die primären Pufferpools. Stellen Sie sicher, dass diese Pools für die Workload entsprechend dimensioniert sind. Wenn Ihre Datenbank mehrere Pufferpool-Instances verwendet, stellen Sie sicher, dass sie nicht in viele kleine Pufferpools unterteilt sind. Threads können jeweils nur einen Pufferpool verwenden.
Stellen Sie sicher, dass die folgenden Speichereinstellungen, die für jeden Thread verwendet werden, richtig dimensioniert sind:
+ read\$1buffer
+ read\$1rnd\$1buffer
+ sort\$1buffer
+ join\$1buffer
+ binlog\$1cache
Wenn Sie keinen bestimmten Grund haben, die Einstellungen zu ändern, verwenden Sie die Standardwerte.
### Untersuchen Sie die Erklärungspläne zur Indexverwendung
Überprüfen Sie bei Abfragen im `sending data`-Thread-Zustand den Plan, um festzustellen, ob geeignete Indizes verwendet werden. Wenn eine Abfrage keinen nützlichen Index verwendet, sollten Sie Hinweise wie `USE INDEX` oder `FORCE INDEX` hinzufügen. Hinweise können die Zeit zum Ausführen einer Abfrage erheblich verlängern oder verkürzen, seien Sie also vorsichtig, bevor Sie sie hinzufügen.
### Überprüfen Sie das Volume der zurückgegebenen Daten
Überprüfen Sie die abgefragten Tabellen und die Menge der Daten, die sie enthalten. Kann irgendeine dieser Daten archiviert werden? In vielen Fällen ist die Ursache für schlechte Ausführungszeiten der Abfragen nicht das Ergebnis des Abfrageplans, sondern das Datenvolumen, das verarbeitet werden soll. Viele Entwickler fügen einer Datenbank sehr effizient Daten hinzu, berücksichtigen jedoch selten den Lebenszyklus von Datensätzen in den Entwurfs- und Entwicklungsphasen.
Suchen Sie nach Abfragen, die in Datenbanken mit geringem Volume gut funktionieren, aber in Ihrem aktuellen System schlecht funktionieren. Manchmal erkennen Entwickler, die bestimmte Abfragen entwerfen, möglicherweise nicht, dass diese Abfragen 350.000 Zeilen zurückgeben. Die Entwickler haben die Abfragen möglicherweise in einer Umgebung mit geringerem Volumen und kleineren Datensätzen entwickelt als in Produktionsumgebungen.
### Auf Parallelitätsprobleme prüfen
Überprüfen Sie, ob mehrere Abfragen desselben Typs gleichzeitig ausgeführt werden. Einige Formen von Abfragen werden effizient ausgeführt, wenn sie alleine laufen. Wenn jedoch ähnliche Abfrageformen zusammen oder in hohem Volumen ausgeführt werden, können sie Parallelitätsprobleme verursachen. Oft werden diese Probleme verursacht, wenn die Datenbank temporäre Tabellen verwendet, um Ergebnisse zu rendern. Eine restriktive Transaktionsisolationsstufe kann auch Parallelitätsprobleme verursachen.
Wenn Tabellen gleichzeitig gelesen und geschrieben werden, verwendet die Datenbank möglicherweise Sperren. Um Perioden schlechter Leistung zu identifizieren, untersuchen Sie die Verwendung von Datenbanken durch umfangreiche Batch-Prozesse. Um die letzten Sperren und Rollbacks anzuzeigen, überprüfen Sie die Ausgabe des `SHOW ENGINE INNODB STATUS`-Befehls.
### Überprüfen der Struktur Ihrer Abfrage
Prüfen Sie, ob erfasste Abfragen aus diesen Status Unterabfragen verwenden. Diese Art von Abfrage führt häufig zu einer schlechten Leistung, da die Datenbank die Ergebnisse intern kompiliert und sie dann wieder in die Abfrage einfügt, um Daten zu rendern. Dieser Prozess ist ein zusätzlicher Schritt für die Datenbank. In vielen Fällen kann dieser Schritt zu einer schlechten Leistung in einem stark gleichzeitigen Ladezustand führen.
Überprüfen Sie auch, ob Ihre Abfragen eine große Anzahl von `ORDER BY`- und `GROUP BY`-Klauseln verwenden. Bei solchen Operationen muss die Datenbank oft zuerst den gesamten Datensatz im Speicher bilden. Dann muss es auf eine bestimmte Weise bestellen oder gruppieren, bevor es an den Kunden zurückgegeben wird.
# Optimierung von Aurora MySQL mit proaktiven Einblicken von Amazon DevOps Guru
Die proaktiven Einblicke von DevOps Guru erkennen bekannte problematische Bedingungen auf Ihren Aurora-MySQL-DB-Clustern, bevor sie auftreten. DevOps Guru kann Folgendes tun:
+ Vermeiden vieler häufig auftretender Datenbankprobleme durch Abgleich der Datenbankkonfiguration mit den allgemein empfohlenen Einstellungen.
+ Warnen vor kritischen Problemen in der Flotte, die, wenn sie nicht überprüft werden, später zu größeren Problemen führen können.
+ Benachrichtigung bei neu erkannten Problemen.
Jeder proaktive Einblick beinhaltet eine Analyse der Problemursache und Empfehlungen für Korrekturmaßnahmen.
**Topics**
+ [Die Länge der InnoDB-Verlaufsliste wurde deutlich erhöht](proactive-insights.history-list.md)
+ [Die Datenbank erstellt temporäre Tabellen auf der Festplatte](proactive-insights.temp-tables.md)
# Die Länge der InnoDB-Verlaufsliste wurde deutlich erhöht
Ab sofort *date* wurde Ihre Verlaufsliste für Zeilenänderungen erheblich erweitert, bis hin *length* *db-instance* zu Dieser Anstieg wirkt sich auf die Leistung beim Herunterfahren von Abfragen und Datenbanken aus.
**Topics**
+ [Unterstützte Engine-Versionen](#proactive-insights.history-list.context.supported)
+ [Kontext](#proactive-insights.history-list.context)
+ [Mögliche Ursachen für dieses Problem](#proactive-insights.history-list.causes)
+ [Aktionen](#proactive-insights.history-list.actions)
+ [Relevante Metriken](#proactive-insights.history-list.metrics)
## Unterstützte Engine-Versionen
Diese Insight-Informationen werden für alle Versionen von unterstützt.
## Kontext
Das InnoDB-Transaktionssystem behält die Multiversion Concurrency Control (MVCC) bei. Wenn eine Zeile geändert wird, wird die Version der geänderten Daten vor der Änderung als Undo-Datensatz in einem Undo-Protokoll gespeichert. Jeder Undo-Datensatz hat einen Verweis auf seinen vorherigen Redo-Datensatz, wodurch eine verknüpfte Liste entsteht.
Die InnoDB-Verlaufsliste ist eine globale Liste der Undo-Protokolle für übernommene Transaktionen. MySQL verwendet die Verlaufsliste, um Datensätze und Protokollseiten zu löschen, wenn Transaktionen den Verlauf nicht mehr benötigen. Die Länge der Verlaufsliste ist die Gesamtzahl der Undo-Protokolle, die Änderungen in der Verlaufsliste enthalten. Jedes Protokoll umfasst eine oder mehrere Änderungen. Wenn die Länge der InnoDB-Verlaufsliste zu groß wird, was auf eine große Anzahl alter Zeilenversionen hinweist, werden Abfragen und Datenbankabschaltungen langsamer.
## Mögliche Ursachen für dieses Problem
Zu den typischen Ursachen einer langen Verlaufsliste gehören die folgenden:
+ Transaktionen mit langer Laufzeit, entweder beim Lesen oder Schreiben
+ Eine hohe Schreiblast
## Aktionen
Abhängig von den Ursachen Ihres Einblicks empfehlen wir verschiedene Aktionen.
**Topics**
+ [Beginnen Sie keine Operation, die ein Herunterfahren der Datenbank beinhaltet, bis die InnoDB-Verlaufsliste kürzer wird](#proactive-insights.history-list.actions.no-shutdown)
+ [Identifizieren und beenden Sie lang andauernde Transaktionen](#proactive-insights.history-list.actions.long-txn)
+ [Verwenden Sie Performance Insights, um die Top-Hosts und Top-Benutzer zu identifizieren.](#proactive-insights.history-list.actions.top-PI)
### Beginnen Sie keine Operation, die ein Herunterfahren der Datenbank beinhaltet, bis die InnoDB-Verlaufsliste kürzer wird
Da eine lange InnoDB-Verlaufsliste das Herunterfahren von Datenbanken verlangsamt, sollten Sie die Listengröße reduzieren, bevor Sie Operationen einleiten, die ein Herunterfahren der Datenbank beinhalten. Zu diesen Vorgängen gehören Datenbank-Upgrades der Hauptversionen.
### Identifizieren und beenden Sie lang andauernde Transaktionen
Sie können Transaktionen mit langer Laufzeit finden, indem Sie `information_schema.innodb_trx` abfragen.
**Anmerkung**
Achten Sie auch darauf, auf Lesereplikaten nach Transaktionen mit langer Laufzeit zu suchen.
**So identifizieren und beenden Sie lang andauernde Transaktionen**
1. Führen Sie das folgende Skript in Ihrem SQL-Client aus:
```
SELECT a.trx_id,
a.trx_state,
a.trx_started,
TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open",
a.trx_rows_modified,
b.USER,
b.host,
b.db,
b.command,
b.time,
b.state
FROM information_schema.innodb_trx a,
information_schema.processlist b
WHERE a.trx_mysql_thread_id=b.id
AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10
ORDER BY trx_started
```
1. Beenden Sie jede lang laufende Transaktion mit dem gespeicherten Verfahren [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
### Verwenden Sie Performance Insights, um die Top-Hosts und Top-Benutzer zu identifizieren.
Optimieren Sie Transaktionen, so dass eine große Anzahl geänderter Zeilen sofort bestätigt wird.
## Relevante Metriken
Die folgenden Metriken beziehen sich auf diesen Einblick:
+ `trx_rseg_history_len` – Diese Zählermetrik kann sowohl in Performance Insights als auch in der Tabelle `INFORMATION_SCHEMA.INNODB_METRICS` angezeigt werden. Weitere Informationen finden Sie in der [Metriktabelle „InnoDB INFORMATION\$1SCHEMA](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html) in der MySQL-Dokumentation.
+ `RollbackSegmentHistoryListLength`— Diese CloudWatch Amazon-Metrik misst die Undo-Logs, in denen festgeschriebene Transaktionen mit als gelöscht markierten Datensätzen aufgezeichnet werden. Diese Datensätze sind für die Verarbeitung durch den InnoDB-Löschvorgang geplant. Die Metrik `trx_rseg_history_len` hat denselben Wert wie `RollbackSegmentHistoryListLength`.
+ `PurgeBoundary` – Die Transaktionsnummer, bis zu der eine InnoDB-Bereinigung zulässig ist. Wenn sich diese CloudWatch Metrik über einen längeren Zeitraum nicht weiterentwickelt, ist dies ein gutes Anzeichen dafür, dass das Löschen von InnoDB durch Transaktionen mit langer Laufzeit blockiert wird. Zur Untersuchung überprüfen Sie die aktiven Transaktionen auf Ihrem Aurora-MySQL-DB-Cluster. Dieser Parameter wird für Aurora-MySQL-Version 2.11 und höher sowie für Version 2.04.5 und höher unterstützt.
+ `PurgeFinishedPoint` – Die Transaktionsnummer, bis zu der eine InnoDB-Bereinigung ausgeführt wird. Mithilfe dieser CloudWatch Metrik können Sie untersuchen, wie schnell die InnoDB-Bereinigung voranschreitet. Dieser Parameter wird für Aurora-MySQL-Version 2.11 und höher sowie für Version 2.04.5 und höher unterstützt.
+ `TransactionAgeMaximum` – Das Alter der ältesten aktiven ausgeführten Transaktion. Diese CloudWatch Metrik ist nur für Aurora MySQL Version 3.08 und höher verfügbar.
+ `TruncateFinishedPoint` – Die Transaktions-ID, bis zu der die Kürzung rückgängig gemacht wird. Diese CloudWatch Metrik ist nur für Aurora MySQL Version 2.11 und höher und Version 3.08 und höher verfügbar.
Weitere Informationen zu den CloudWatch Metriken finden Sie unter. [Metriken auf Instance-Ebene für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)
# Die Datenbank erstellt temporäre Tabellen auf der Festplatte
Ihre aktuelle Nutzung temporärer Tabellen auf der Festplatte hat erheblich zugenommen, bis zu*percentage*. Die Datenbank erstellt ungefähr *number* temporäre Tabellen pro Sekunde. Dies kann sich auf die Leistung auswirken und die Anzahl der Festplattenoperationen erhöhen*db-instance*.
**Topics**
+ [Unterstützte Engine-Versionen](#proactive-insights.temp-tables.context.supported)
+ [Kontext](#proactive-insights.temp-tables.context)
+ [Mögliche Ursachen für dieses Problem](#proactive-insights.temp-tables.causes)
+ [Aktionen](#proactive-insights.temp-tables.actions)
+ [Relevante Metriken](#proactive-insights.temp-tables.metrics)
## Unterstützte Engine-Versionen
Diese Insight-Informationen werden für alle Versionen von unterstützt.
## Kontext
Manchmal ist es notwendig, dass der MySQL-Server während der Verarbeitung einer Abfrage eine interne temporäre Tabelle erstellt. Aurora MySQL kann eine interne temporäre Tabelle im Speicher speichern, wo sie von der Speicher-Engine TempTable oder MEMORY verarbeitet oder von InnoDB auf der Festplatte gespeichert werden kann. Weitere Informationen finden Sie unter [Interne Verwendung temporärer Tabellen in MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html) im *MySQL-Referenzhandbuch*.
## Mögliche Ursachen für dieses Problem
Eine Zunahme temporärer Tabellen auf der Festplatte weist auf die Verwendung komplexer Abfragen hin. Wenn der konfigurierte Speicher nicht ausreicht, um temporäre Tabellen im Speicher zu speichern, erstellt Aurora MySQL die Tabellen auf der Festplatte. Dies kann die Leistung beeinträchtigen und den Festplattenbetrieb erhöhen.
## Aktionen
Abhängig von den Ursachen Ihres Einblicks empfehlen wir verschiedene Aktionen.
+ Für Aurora MySQL Version 3 empfehlen wir die Verwendung der TempTable Speicher-Engine.
+ Optimieren Sie Ihre Abfragen, um weniger Daten zurückzugeben, indem Sie nur die erforderlichen Spalten auswählen.
Wenn Sie das Performance-Schema aktivieren und alle `statement`-Instrumente aktiviert und zeitgesteuert sind, können Sie `SYS.statements_with_temp_tables` abfragen, um die Liste der Abfragen abzurufen, die temporäre Tabellen verwenden. Weitere Informationen finden Sie unter [Voraussetzungen für die Verwendung des sys–Schemas](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html) in der MySQL-Dokumentation.
+ Erwägen Sie die Indizierung von Spalten, die an Sortier- und Gruppierungsoperationen beteiligt sind.
+ Schreiben Sie Ihre Abfragen neu, um `BLOB`- und `TEXT`-Spalten zu vermeiden. Diese Spalten verwenden immer die Festplatte.
+ Optimieren Sie die folgenden Datenbankparameter: `tmp_table_size` und `max_heap_table_size`.
Der Standardwert für diese Parameter ist 16 MiB. Wenn Sie die MEMORY-Speicher-Engine für temporäre In-Memory-Tabellen verwenden, wird deren maximale Größe durch den `tmp_table_size`- oder `max_heap_table_size`-Wert definiert, je nachdem, welcher Wert kleiner ist. Wenn diese maximale Größe erreicht ist, konvertiert MySQL die interne temporäre In-Memory-Tabelle automatisch in eine interne temporäre InnoDB-Tabelle auf der Festplatte. Weitere Informationen finden Sie unter [Verwenden der TempTable Speicher-Engine auf Amazon RDS for MySQL und Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
**Anmerkung**
Beim expliziten Erstellen von MEMORY-Tabellen mit CREATE TABLE bestimmt nur die `max_heap_table_size`-Variable, wie groß eine Tabelle werden kann. Es erfolgt auch keine Konvertierung in ein Festplattenformat.
## Relevante Metriken
Die folgenden Performance Insights-Metriken beziehen sich auf diesen Einblick:
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
Weitere Informationen finden Sie unter [Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables) in der MySQL-Dokumentation.