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.
# 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.