synch/cond/innodb/row_lock_wait_cond

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 Blocco in InnoDB nel Riferimento 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.

Operazioni

Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.

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 blogAnalizza i carichi di lavoro di Amazon Aurora MySQL con Approfondimenti sulle prestazioni.

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.

Per ulteriori informazioni su come identificare le transazioni di blocco, consulta Utilizzo delle informazioni sulle transazioni InnoDB e sul blocco nel Manuale di riferimento di MySQL.