# synch/cond/innodb/row\$1lock\$1wait
El evento `synch/cond/innodb/row_lock_wait` se produce cuando una sesión ha bloqueado una fila para una actualización y otra sesión intenta actualizar la misma fila. Para obtener información, consulte [InnoDB Locking](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) en la documentación de MySQL.
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL versión 3
## Causas probables del aumento de las esperas
Las múltiples instrucciones de lenguaje de manipulación de datos (DML) tienen acceso a la misma fila o filas simultáneamente.
## Acciones
Recomendamos diferentes acciones en función de los demás eventos de espera que vea.
**Topics**
+ [Buscar y responder a las instrucciones SQL responsables de este evento de espera](#ams-waits.row-lock-wait.actions.id)
+ [Buscar y responder a la sesión de bloqueo](#ams-waits.row-lock-wait.actions.blocker)
### Buscar y responder a las instrucciones SQL responsables de este evento de espera
Utilice Información sobre rendimiento para identificar las instrucciones SQL responsables de este evento de espera. Consideremos la posibilidad de aplicar las estrategias siguientes:
+ Si los bloqueos de fila son un problema persistente, considere la posibilidad de reescribir la aplicación para utilizar un bloqueo optimista.
+ Utilice instrucciones de varias filas.
+ Distribuya la carga de trabajo en distintos objetos de base de datos. Puede hacerlo mediante una partición.
+ Verifique el valor del parámetro `innodb_lock_wait_timeout`. Controla cuánto tiempo esperan las transacciones antes de generar un error de tiempo de espera.
Para obtener información general útil sobre la solución de problemas mediante Información sobre rendimiento, consulte la entrada de blog [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Buscar y responder a la sesión de bloqueo
Determine si la sesión de bloqueo está inactiva o activa. Además, averigüe si la sesión procede de una aplicación o de un usuario activo.
Para identificar la sesión que mantiene el candado, puede ejecutar `SHOW ENGINE INNODB STATUS`. A continuación se muestra un resultado de ejemplo.
```
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
```
O bien, puede utilizar la siguiente consulta para extraer detalles sobre los bloqueos actuales.
```
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)
```
Cuando identifique la sesión, puede seguir una de las opciones siguientes:
+ Ponerse en contacto con el propietario o el usuario de la aplicación.
+ Si la sesión de bloqueo está inactiva, considere la posibilidad de finalizar la sesión de bloqueo. Esta acción podría desencadenar una larga restauración. Para aprender a finalizar una sesión, consulte [Finalización de una sesión o una consulta](mysql-stored-proc-ending.md).
Para obtener más información acerca de cómo identificar las transacciones de bloqueo, consulte [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html) en la documentación de MySQL.