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