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_blocca_aspetta
L’evento synch/cond/innodb/row_lock_wait
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 InnoDB locking nella mia
Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
-
Aurora La mia versione 3 SQL
Probabili cause di aumento delle attese
Più istruzioni Data Manipulation Language (DML) accedono alla stessa riga o alle stesse righe contemporaneamente.
Azioni
Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.
Argomenti
Trova e rispondi alle SQL dichiarazioni responsabili di questo evento di attesa
Usa Performance Insights per identificare le SQL dichiarazioni 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 un'utile panoramica sulla risoluzione dei problemi con Performance Insights, consulta il post del blog Analizza i miei SQL carichi di lavoro di Amazon Aurora con 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 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
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_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)
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 sull'identificazione delle transazioni bloccanti, vedere Utilizzo della transazione InnoDB e blocco delle informazioni nella mia