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/cond/innodb/row\$1bloquer\$1attendre
L’événement `synch/cond/innodb/row_lock_wait` se produit lorsqu’une session a verrouillé une ligne pour une mise à jour et qu’une autre session tente de mettre à jour cette même ligne. Pour plus d’informations, consultez [InnoDB Locking](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) dans la documentation MySQL.
## Versions de moteur prises en charge
Ces informations relatives aux événements d’attente sont prises en charge pour les versions de moteur suivantes :
+ Aurora MySQL version 3
## Causes probables de l’augmentation du nombre d’événements d’attente
Plusieurs instructions en langage de manipulation de données (DML) accèdent simultanément aux mêmes lignes.
## Actions
Nous recommandons différentes actions en fonction des autres événement d’attente que vous voyez.
**Topics**
+ [
### Rechercher et répondre aux instructions SQL responsables de cet événement d’attente
](#ams-waits.row-lock-wait.actions.id)
+ [
### Rechercher et répondre à la session de blocage
](#ams-waits.row-lock-wait.actions.blocker)
### Rechercher et répondre aux instructions SQL responsables de cet événement d’attente
Utilisez Performance Insights pour identifier les instructions SQL responsables de cet événement d’attente. Envisagez les stratégies suivantes :
+ Si les verrous de ligne posent un problème persistant, pensez à réécrire l’application de manière à utiliser un verrouillage optimiste.
+ Utiliser plusieurs instructions
+ Répartissez la charge de travail sur différents objets de base de données. Vous pouvez le faire via le partitionnement.
+ Vérifiez la valeur du paramètre `innodb_lock_wait_timeout`. Il contrôle le délai d’attente des transactions avant de générer une erreur de dépassement.
Pour une présentation de la résolution des problèmes à 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/).
### Rechercher et répondre à la session de blocage
Déterminez si la session de blocage est active ou inactive. Vérifiez également si la session provient d’une application ou d’un utilisateur actif.
Pour identifier la session maintenant le verrou, vous pouvez exécuter `SHOW ENGINE INNODB STATUS`. L’exemple suivant illustre une sortie.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
Vous pouvez également utiliser la requête suivante pour extraire des détails sur les verrous en cours.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_id = it.trx_id join information_schema.processlist p
ON it.trx_mysql_thread_id = p.id join information_schema.innodb_trx it1
ON ilw.requesting_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
Après avoir identifié la session, vous pouvez procédez comme suit :
+ Contactez le propriétaire de l’application ou l’utilisateur.
+ Si la session de blocage est inactive, pensez à y mettre fin. Une telle action peut déclencher une longue restauration. Pour savoir comment mettre fin à une session, consultez [Mettre fin à une session ou à une requête](mysql-stored-proc-ending.md).
Pour plus d’informations sur l’identification des transactions de blocage, consultez [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html) dans la documentation MySQL.