Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# synch/mutex/innodb/trx\$1sys\$1mutex
L'événement `synch/mutex/innodb/trx_sys_mutex` se produit lorsque l'activité de base de données est élevée et présente un grand nombre de transactions.
**Topics**
+ [Versions de moteur pertinentes](#ams-waits.trxsysmutex.context.supported)
+ [Contexte](#ams-waits.trxsysmutex.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#ams-waits.trxsysmutex.causes)
+ [Actions](#ams-waits.trxsysmutex.actions)
## Versions de moteur pertinentes
Ces informations relatives aux événements d’attente sont prises en charge pour les versions de moteur suivantes :
+ Aurora MySQL versions 2 et 3
## Contexte
En interne, le moteur de base de données InnoDB utilise le niveau d'isolement de lecture renouvelée avec instantanés pour assurer la cohérence en lecture. Cela vous donne une point-in-time vue de la base de données au moment de la création de l'instantané.
Dans InnoDB, toutes les modifications sont appliquées à la base de données dès leur arrivée, qu'elles soient validées ou non. Une telle approche signifie que sans contrôle de simultanéité multiversion (MVCC), tous les utilisateurs connectés à la base de données voient toutes les modifications et les dernières lignes. Par conséquent, InnoDB doit pouvoir suivre les modifications pour comprendre les éléments à annuler, si nécessaire.
Pour ce faire, InnoDB utilise un système de transactions (`trx_sys`) lui permettant de suivre les instantanés. Le système de transactions procède comme suit :
+ Il suit l'ID de transaction de chaque ligne dans les journaux d'annulation.
+ Utilise une structure InnoDB interne appelée `ReadView` qui permet d'identifier les transactions IDs visibles pour un instantané.
## Causes probables de l’augmentation du nombre d’événements d’attente
Toute opération de base de données qui nécessite une gestion cohérente et contrôlée (création, lecture, mise à jour et suppression) des transactions IDs génère un appel depuis `trx_sys` le mutex.
Ces appels se produisent dans trois fonctions :
+ `trx_sys_mutex_enter` – Crée le mutex.
+ `trx_sys_mutex_exit` – Libère le mutex.
+ `trx_sys_mutex_own` – Teste si le mutex a un propriétaire.
L'instrumentation du schéma de performance InnoDB suit tous les appels du mutex `trx_sys`. Le suivi inclut, sans s'y limiter, les opérations suivantes : gestion de `trx_sys` lorsque la base de données démarre ou s'arrête, restaurations, nettoyages après annulation, accès en lecture de ligne et charges de groupe de mémoires tampons. Une activité de base de données élevée avec un grand nombre de transactions entraîne l'apparition de `synch/mutex/innodb/trx_sys_mutex` parmi les principaux événements d'attente.
Pour plus d'informations, consultez [Monitoring InnoDB Mutex Waits Using Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) dans la documentation MySQL.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [Identifier les sessions et les requêtes à l'origine des événements](#ams-waits.trxsysmutex.actions.identify)
+ [Examiner d'autres événements d'attente](#ams-waits.trxsysmutex.actions.action1)
### Identifier les sessions et les requêtes à l'origine des événements
En règle générale, les bases de données à charge modérée à importante présentent des événements d’attente. Les événements d'attente peuvent être acceptables si les performances sont optimales. Si les performances ne sont pas optimales, voyez où la base de données passe le plus de temps. Examinez les événements d'attente qui contribuent à la charge la plus élevée. Voyez si vous pouvez optimiser la base de données et l'application de manière à réduire ces événements.
**Pour afficher le graphique Top SQL dans le AWS Management Console**
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Performance Insights**.
1. Choisissez une instance de base de données. Le tableau de bord Performance Insights s’affiche pour cette instance de base de données.
1. Dans le graphique **Database load (Charge de base de données)**, choisissez **Slice by wait (Tranche par attente)**.
1. Sous le graphique **Data load (Charge de base de données)**, choisissez**Top SQL (Principaux éléments SQL)**.
Le graphique répertorie les requêtes SQL responsables de la charge. Les requêtes situées en haut de la liste sont les plus responsables. Pour résoudre un goulet d’étranglement, concentrez-vous sur ces instructions.
Pour une vue d'ensemble de la résolution des problème à l'aide de Performance Insights, consultez le billet de blog[Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Examiner d'autres événements d'attente
Examinez les autres événements d'attente associés à l'événement d'attente `synch/mutex/innodb/trx_sys_mutex`. Ils peuvent vous fournir plus d'informations sur la nature de la charge de travail. Un grand nombre de transactions peuvent réduire le débit, mais la charge de travail peut également l'imposer.
Pour en savoir plus sur l'optimisation des transactions, consultez [Optimizing InnoDB Transaction Management](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)dans la documentation MySQL.