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/cond/innodb/row\$1lock\$1wait\$1cond
L’evento `synch/cond/innodb/row_lock_wait_cond` si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. Per ulteriori informazioni, consulta l'argomento sul [blocco in InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) nella documentazione di MySQL.
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2
## Probabili cause di aumento delle attese
Le diverse istruzioni relative al linguaggio di manipolazione dei dati (DML) accedono contemporaneamente alla stessa riga o righe.
## Azioni
Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.
**Topics**
+ [Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa](#ams-waits.row-lock-wait-cond.actions.id)
+ [Trova e rispondi alla sessione di blocco](#ams-waits.row-lock-wait-cond.actions.blocker)
### Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa
Utilizzare Approfondimenti sulle prestazioni per identificare le istruzioni SQL responsabili di questo evento di attesa. Considera le strategie seguenti:
+ Se i blocchi di riga sono un problema persistente, considera la possibilità di riscrivere l'applicazione per utilizzare il blocco ottimistico.
+ Utilizza istruzioni multiriga.
+ Distribuisci il carico di lavoro su diversi oggetti di database. Per farlo, puoi utilizzare il partizionamento.
+ Verifica il valore del parametro `innodb_lock_wait_timeout`. Controlla la durata di attesa delle transazioni prima di generare un errore di timeout.
Per una panoramica utile dell’identificazione e della risoluzione dei problemi con Approfondimenti sulle prestazioni, consulta il post del blog[Analizza i carichi di lavoro di Amazon Aurora MySQL con Approfondimenti sulle prestazioni](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Trova e rispondi alla sessione di blocco
Determina se la sessione di blocco è inattiva o attiva. Inoltre, scopri se la sessione proviene da un'applicazione o da un utente attivo.
Per identificare la sessione che tiene il blocco, è possibile eseguire `SHOW ENGINE INNODB STATUS`. Il seguente esempio mostra un output campione.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
In alternativa, è possibile usare la seguente query per estrarre i dettagli sui blocchi correnti.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_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_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Quando si identifica la sessione, le opzioni includono quanto segue:
+ Contattare il proprietario dell'applicazione o l'utente.
+ Se la sessione di blocco è inattiva, considerare di terminare la sessione di blocco. Questa azione potrebbe innescare un lungo ripristino dello stato precedente. Per informazioni su come terminare una sessione, consulta [Terminare una sessione o una query](mysql-stored-proc-ending.md).
Per ulteriori informazioni su come identificare le transazioni di blocco, consulta [Using InnoDB transaction and locking information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) nella documentazione di MySQL.