Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# synch/mutex/innodb/trx\$1sys\$1mutex
<a name="ams-waits.trxsysmutex"></a>

L’evento `synch/mutex/innodb/trx_sys_mutex` si verifica quando c'è un'elevata attività del database con un numero elevato di transazioni.

**Topics**
+ [Versioni del motore rilevanti](#ams-waits.trxsysmutex.context.supported)
+ [Contesto](#ams-waits.trxsysmutex.context)
+ [Probabili cause di aumento delle attese](#ams-waits.trxsysmutex.causes)
+ [Azioni](#ams-waits.trxsysmutex.actions)

## Versioni del motore rilevanti
<a name="ams-waits.trxsysmutex.context.supported"></a>

Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3

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

Internamente, il motore di database InnoDB utilizza il livello di isolamento della lettura ripetibile con snapshot per fornire coerenza di lettura. Ciò consente di point-in-time visualizzare il database al momento della creazione dello snapshot.

In InnoDB, tutte le modifiche vengono applicate al database non appena arrivano, indipendentemente dal fatto che sia stato eseguito il commit. Questo approccio significa che senza il controllo della concorrenza multiversione (MVCC), tutti gli utenti connessi al database vedono tutte le modifiche e le righe più recenti. Pertanto, InnoDB richiede un modo per tenere traccia delle modifiche per capire cosa ripristinare allo stato precedente quando necessario.

Per fare ciò, InnoDB utilizza un sistema di transazioni (`trx_sys`) per tenere traccia degli snapshot. Il sistema di transazioni effettua quanto segue:
+ Tiene traccia dell'ID della transazione per ogni riga nei registri di annullamento.
+ Utilizza una struttura interna di InnoDB chiamata `ReadView` che aiuta a identificare quali transazioni IDs sono visibili per un'istantanea.

## Probabili cause di aumento delle attese
<a name="ams-waits.trxsysmutex.causes"></a>

Qualsiasi operazione di database che richieda la gestione coerente e controllata (creazione, lettura, aggiornamento ed eliminazione) delle transazioni IDs genera una chiamata dal mutex`trx_sys`.

Queste chiamate avvengono all'interno di tre funzioni:
+ `trx_sys_mutex_enter` – Crea il mutex.
+ `trx_sys_mutex_exit` – Rilascia il mutex.
+ `trx_sys_mutex_own` – Verifica se il mutex è di proprietà.

La strumentazione InnoDB Performance Schema tiene traccia di tutte le chiamate mutex `trx_sys`. Il monitoraggio include, a titolo esemplificativo ma non esaustivo, la gestione di `trx_sys` all'avvio o allo spegnimento del database, operazioni di ripristino dello stato precedente, pulizia degli annullamenti, accesso in lettura di righe e carichi del pool di buffer. L'elevata attività del database con un numero elevato di transazioni comporta la comparsa di `synch/mutex/innodb/trx_sys_mutex` tra i principali eventi di attesa.

Per ulteriori informazioni, consulta [Monitoraggio delle attese di Mutex di InnoDB utilizzando lo schema delle prestazioni](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) nella documentazione di MySQL.

## Azioni
<a name="ams-waits.trxsysmutex.actions"></a>

Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.

**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.trxsysmutex.actions.identify)
+ [Esamina altri eventi di attesa](#ams-waits.trxsysmutex.actions.action1)

### Identificare le sessioni e le query che causano gli eventi
<a name="ams-waits.trxsysmutex.actions.identify"></a>

In genere, i database con carico da moderato a significativo hanno eventi di attesa. Gli eventi di attesa possono essere accettabili se le prestazioni sono ottimali. Se le prestazioni non sono ottimali, esaminare dove il database impiega più tempo. Guarda gli eventi di attesa che contribuiscono al carico più elevato. Scopri se è possibile ottimizzare il database e l'applicazione per ridurre tali eventi.

**Per visualizzare il grafico Top SQL nel Console di gestione AWS**

1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Nel pannello di navigazione scegli **Approfondimenti sulle prestazioni**.

1. Scegli un'istanza database. Viene visualizzato il pannello di controllo di Approfondimenti sulle prestazioni per l'istanza database.

1. Nel grafico **Carico del database**, scegli **Dividi per attesa**.

1. Nel grafico **Carico del database**, seleziona **Prime istruzioni SQL**.

   Il grafico elenca le query di SQL responsabili del carico. Quelli in cima all'elenco sono le più responsabili. Per risolvere un collo di bottiglia, occorre concentrarsi su queste istruzioni.

Per una panoramica utile dell’identificazione e della risoluzione dei problemi con Performance Insights, consulta il post del blog[Analizza i carichi di lavoro di Amazon Aurora MySQL con Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).

### Esamina altri eventi di attesa
<a name="ams-waits.trxsysmutex.actions.action1"></a>

Esamina gli altri eventi di attesa associati all’evento di attesa `synch/mutex/innodb/trx_sys_mutex`. In questo modo, si possono acquisire ulteriori informazioni sulla natura del carico di lavoro. Un numero elevato di transazioni potrebbe ridurre la velocità effettiva, ma anche il carico di lavoro potrebbe renderlo necessario.

Per ulteriori informazioni su come ottimizzare le transazioni, consulta [Ottimizzazione della gestione delle transazioni InnoDB](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) nella documentazione di MySQL.