# synch/cond/innodb/row\$1lock\$1wait
O evento `synch/cond/innodb/row_lock_wait` ocorre quando uma sessão bloqueou uma linha para uma atualização e outra linha tenta atualizar a mesma linha. Para obter mais informações, consulte o tópico sobre [InnoDB locking](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) na documentação do MySQL.
## Versões compatíveis do mecanismo
Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:
+ Aurora MySQL versão 3
## Possíveis causas do maior número de esperas
Várias instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas simultaneamente.
## Ações
Recomendamos diferentes ações dependendo dos outros eventos de espera exibidos.
**Topics**
+ [Localizar e responder às instruções SQL responsáveis por esse evento de espera](#ams-waits.row-lock-wait.actions.id)
+ [Localizar e responder à sessão de bloqueio](#ams-waits.row-lock-wait.actions.blocker)
### Localizar e responder às instruções SQL responsáveis por esse evento de espera
Utilize o Performance Insights para identificar as instruções SQL responsáveis por esse evento de espera. Considere as estratégias a seguir:
+ Se bloqueios de linha forem um problema persistente, considere reescrever a aplicação para utilizar o bloqueio otimista.
+ Utilize instruções de várias linhas.
+ Disperse a workload por objetos de banco de dados diferentes. É possível fazer isso por meio de particionamento.
+ Verifique o valor do parâmetro `innodb_lock_wait_timeout`. Ele controla quanto tempo as transações aguardam antes de gerarem um erro de tempo limite.
Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a Publicação no blog sobre como [Analisar workloads do Amazon Aurora MySQL com o Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Localizar e responder à sessão de bloqueio
Determine se a sessão de bloqueio está ociosa ou ativa. Além disso, descubra se a sessão é proveniente de uma aplicação ou de um usuário ativo.
Para identificar a sessão que está mantendo o bloqueio, é possível executar `SHOW ENGINE INNODB STATUS`. O exemplo a seguir mostra uma saída.
```
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
```
Outra alternativa é utilizar a consulta a seguir para extrair detalhes sobre os bloqueios atuais.
```
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)
```
Ao identificar a sessão, suas opções incluem:
+ Entre em contato com o proprietário da aplicação ou o usuário.
+ Se a sessão de bloqueio estiver ociosa, considere encerrá-la. Essa ação pode desencadear uma reversão longa. Para saber como encerrar uma sessão, consulte [Encerrar uma sessão ou consulta](mysql-stored-proc-ending.md).
Para obter mais informações sobre como identificar transações de bloqueio, consulte [Uso de informações de transações e bloqueios do InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html), na documentação do MySQL.