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/trx\$1sys\$1mutex
<a name="ams-waits.trxsysmutex"></a>

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
<a name="ams-waits.trxsysmutex.context.supported"></a>

Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Versionen 2 und 3

## Kontext
<a name="ams-waits.trxsysmutex.context"></a>

Intern verwendet das InnoDB-Datenbankmodul die wiederholbare Lese-Isolationsstufe mit Snapshots, um Lesekonsistenz zu gewährleisten. Dadurch erhalten Sie einen point-in-time Überblick über die 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`, mit deren Hilfe identifiziert werden kann, welche Transaktionen für einen Snapshot sichtbar IDs sind.

## Wahrscheinliche Ursachen für erhöhte Wartezeiten
<a name="ams-waits.trxsysmutex.causes"></a>

Jeder Datenbankvorgang, der die konsistente und kontrollierte Verarbeitung (Erstellen, Lesen, Aktualisieren und Löschen) von Transaktionen erfordert, IDs generiert 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
<a name="ams-waits.trxsysmutex.actions"></a>

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
<a name="ams-waits.trxsysmutex.actions.identify"></a>

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.

**Um das Top-SQL-Diagramm in der AWS-Managementkonsole**

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
<a name="ams-waits.trxsysmutex.actions.action1"></a>

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.