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/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*.