Ottenere "Timeout attesa di blocco superato; prova a riavviare la transazione "anche se non sto utilizzando una transazione

Sto eseguendo la seguente UPDATEdichiarazione MySQL :

mysql> update customer set account_import_id = 1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Non sto usando una transazione, quindi perché dovrei ricevere questo errore? Ho anche provato a riavviare il mio server MySQL e non ha aiutato.

La tabella ha 406.733 righe.

Stai utilizzando una transazione; autocommit non disabilita le transazioni, le fa semplicemente impegnare automaticamente alla fine dell'istruzione.

Quello che sta succedendo è che qualche altro thread ha un blocco dei record su un record (stai aggiornando tutti i record nella tabella!) Per troppo tempo e il tuo thread è scaduto.

Puoi vedere maggiori dettagli sull'evento emettendo un

SHOW ENGINE INNODB STATUS

dopo l'evento (in sqleditor). Idealmente, fallo su una macchina di prova silenziosa.

COME FORZARE IL SBLOCCO per le tabelle bloccate in MySQL:

La rottura di blocchi come questo può impedire l' atomicità nel database sulle istruzioni sql che hanno causato il blocco.

Questo è un trucco, e la soluzione corretta è quella di riparare la tua applicazione che ha causato i blocchi. Tuttavia, quando i dollari sono in linea, un calcio rapido farà muovere di nuovo le cose.

1) Inserisci MySQL

mysql -u your_user -p

2) Vediamo l'elenco delle tabelle bloccate

mysql> show open tables where in_use>0;

3) Vediamo la lista dei processi correnti, uno di questi sta bloccando le tue tabelle

mysql> show processlist;

4) Uccidi uno di questi processi

mysql> kill <put_process_id_here>;

mysql> set innodb_lock_wait_timeout=100

Query OK, 0 rows affected (0.02 sec)

mysql> show variables like 'innodb_lock_wait_timeout';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 100   |
+--------------------------+-------+

Ora attiva nuovamente il blocco. Hai 100 secondi di tempo per inviare un SHOW ENGINE INNODB STATUS\Gal database e vedere quale altra transazione sta bloccando la tua.

Dai un'occhiata se il tuo database è ottimizzato. Soprattutto l'isolamento delle transazioni. Non è una buona idea aumentare la variabile innodb_lock_wait_timeout.

Controlla il livello di isolamento delle transazioni del database nel mysql cli:

mysql> SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation, @@session.transaction_isolation;
+-----------------------+-----------------+------------------------+
| @@GLOBAL.tx_isolation | @@tx_isolation  | @@session.tx_isolation |
+-----------------------+-----------------+------------------------+
| REPEATABLE-READ       | REPEATABLE-READ | REPEATABLE-READ        |
+-----------------------+-----------------+------------------------+
1 row in set (0.00 sec)

Potresti ottenere miglioramenti cambiando il livello di isolamento, usare l'oracolo come LEGGI IMPEGNATO invece RIPETIBILE LEGGI (Predefiniti InnoDB)

mysql> SET tx_isolation = 'READ-COMMITTED';
Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL tx_isolation = 'READ-COMMITTED';
Query OK, 0 rows affected (0.00 sec)

mysql> 

Prova anche a utilizzare SELEZIONA PER AGGIORNAMENTO solo se necessario.

Nessuna delle soluzioni suggerite ha funzionato per me ma questo ha funzionato.

Qualcosa sta bloccando l'esecuzione della query. Molto probabilmente un'altra query che aggiorna, inserisce o elimina da una delle tabelle nella query. Devi scoprire di cosa si tratta:

SHOW PROCESSLIST;

Una volta individuato il processo di blocco, trovalo ided esegui:

KILL {id};

Rieseguire la query iniziale.

100% con quanto affermato da MarkR. autocommit rende ogni istruzione una transazione con una sola istruzione.

SHOW ENGINE INNODB STATUSdovrebbe darti alcuni indizi sulla ragione del deadlock. Dai un'occhiata anche al log delle query lente per vedere cos'altro sta eseguendo una query sulla tabella e prova a rimuovere tutto ciò che sta eseguendo una scansione completa delle tabelle. Il blocco a livello di riga funziona bene ma non quando si tenta di bloccare tutte le righe!

È possibile aggiornare qualsiasi altro record all'interno di questa tabella o questa tabella è ampiamente utilizzata? Quello che sto pensando è che mentre sta tentando di acquisire un blocco, è necessario aggiornare questo record. Il timeout impostato è scaduto. Potresti essere in grado di aumentare il tempo utile.

Il numero di righe non è enorme ... Crea un indice su account_import_id se non è la chiave primaria.

CREATE INDEX idx_customer_account_import_id ON customer (account_import_id);

Se hai appena ucciso una query di grandi dimensioni, ci vorrà del tempo per rollback. Se si emette un'altra query prima del rollback della query interrotta, è possibile che si verifichi un errore di timeout del blocco. Questo è quello che mi è successo. La soluzione era solo aspettare un po '.

Dettagli:

Avevo inviato una query DELETE per rimuovere circa 900.000 su circa 1 milione di righe.

L'ho eseguito per errore (rimuove solo il 10% delle righe): DELETE FROM table WHERE MOD(id,10) = 0

Invece di questo (rimuove il 90% delle righe): DELETE FROM table WHERE MOD(id,10) != 0

Volevo rimuovere il 90% delle righe, non il 10%. Quindi ho interrotto il processo nella riga di comando di MySQL, sapendo che avrebbe eseguito il rollback di tutte le righe che aveva eliminato finora.

Quindi ho eseguito immediatamente il comando corretto e lock timeout exceededsubito dopo ho ricevuto un errore. Mi sono reso conto che il blocco potrebbe effettivamente essere la rollbackquery uccisa che sta ancora accadendo in background. Quindi ho atteso qualche secondo e ho eseguito nuovamente la query.

Accertarsi che le tabelle del database stiano utilizzando il motore di archiviazione InnoDB e il livello di isolamento della transazione LEGGI-COMMITTATO.

Puoi verificarlo selezionando SELECT @@ GLOBAL.tx_isolation, @@ tx_isolation; sulla console mysql.

Se non è impostato su READ-COMMITTED, è necessario impostarlo. Assicurati prima di impostare che hai i privilegi SUPER in mysql.

Puoi chiedere aiuto su http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html .

Impostando questo penso che il tuo problema verrà risolto.

Potresti anche voler verificare che non stai tentando di aggiornare questo in due processi contemporaneamente. Gli utenti (@tala) hanno riscontrato messaggi di errore simili in questo contesto, forse ricontrollare che ...

Sono venuto da Google e volevo solo aggiungere la soluzione che funzionava per me. Il mio problema era che stavo cercando di eliminare i record di una tabella enorme che aveva un sacco di FK in cascata, quindi ho avuto lo stesso errore dell'OP.

Ho disabilitato autocommite poi ha funzionato solo aggiungendo COMMITalla fine della frase SQL. Per quanto ho capito, questo rilascia il buffer bit per bit invece di attendere alla fine del comando.

Per mantenere l'esempio del PO, questo avrebbe dovuto funzionare:

mysql> set autocommit=0;

mysql> update customer set account_import_id = 1; commit;

Non dimenticare di riattivare autocommitnuovamente se vuoi lasciare la configurazione di MySQL come prima.

mysql> set autocommit=1;

In ritardo alla festa (come al solito), tuttavia, il mio problema era il fatto che ho scritto un po 'di SQL errato (essendo un novizio) e diversi processi avevano un blocco sui record <- non sono sicuro della verbosità appropriata. Ho finito per dover solo: SHOW PROCESSLISTe poi uccidere gli ID usandoKILL <id>

Questo genere di cose mi è successo quando stavo usando exit di costruzione del linguaggio php; nel mezzo della transazione. Quindi questa transazione "si blocca" e devi terminare il processo mysql (descritto sopra con processlist;)

Nel mio caso, stavo eseguendo una query anomala per correggere i dati. Se blocchi le tabelle nella tua query, non dovrai occuparti del timeout di blocco:

LOCK TABLES `customer` WRITE;
update customer set account_import_id = 1;
UNLOCK TABLES;

Questa probabilmente non è una buona idea per un uso normale.

Per maggiori informazioni, consultare: Manuale di riferimento di MySQL 8.0

Mi sono imbattuto in questo avendo 2 connessioni DBAL Doctrine, una delle quali non transazionali (per i registri importanti), sono destinate a funzionare in parallelo non dipendono l'una dall'altra.

CodeExecution(
    TransactionConnectionQuery()
    TransactionlessConnectionQuery()
)

I miei test di integrazione sono stati inseriti in transazioni per il rollback dei dati dopo molto test.

beginTransaction()
CodeExecution(
    TransactionConnectionQuery()
    TransactionlessConnectionQuery() // CONFLICT
)
rollBack()

La mia soluzione era disabilitare la transazione di wrapping in quei test e ripristinare i dati del db in un altro modo.

Ho avuto lo stesso errore, anche se stavo aggiornando solo una tabella con una voce, ma dopo aver riavviato mysql, è stato risolto.