Naprawianie "przekroczony limit czasu oczekiwania na blokadę; spróbuj ponownie uruchomić transakcję" dla "zablokowanej" tabeli Mysql?

Miałem podobny problem i rozwiązałem go, sprawdzając uruchomione wątki. Aby zobaczyć uruchomione wątki, użyj następującego polecenia w interfejsie wiersza poleceń mysql:

SHOW PROCESSLIST;

Może być również wysłany z phpMyAdmin, jeśli nie masz dostępu do interfejsu linii poleceń mysql.
Spowoduje to wyświetlenie listy wątków z odpowiednimi identyfikatorami i czasem wykonania, dzięki czemu można zabić wątki, które zajmują zbyt dużo czasu. W phpMyAdmin będziesz miał przycisk do zatrzymywania wątków używając KILL, jeśli używasz interfejsu wiersza poleceń, po prostu użyj polecenia KILL, a następnie id wątku, jak w poniższym przykładzie:

KILL 115;

Spowoduje to zakończenie połączenia dla odpowiedniego wątku.

Możesz sprawdzić bieżące transakcje za pomocą

SELECT * FROM `information_schema`.`innodb_trx` ORDER BY `trx_started`

Twoja transakcja powinna być jedną z pierwszych, ponieważ jest najstarsza na liście. Teraz po prostu weź wartość z trx_mysql_thread_id i wyślij ją KILL poleceniem:

KILL 1234;

Jeśli nie masz pewności, która transakcja należy do ciebie, powtarzaj pierwsze zapytanie bardzo często i sprawdź, które transakcje trwają.

Sprawdź stan InnoDB dla zamków

SHOW ENGINE InnoDB STATUS;

Sprawdź otwarte tabele MySQL

SHOW OPEN TABLES WHERE In_use > 0;

Sprawdź oczekujące transakcje InnoDB

SELECT * FROM `information_schema`.`innodb_trx` ORDER BY `trx_started`; 

Check lock dependency-co blokuje co

SELECT * FROM `information_schema`.`innodb_locks`;

Po zbadaniu powyższych wyników, powinieneś być w stanie zobaczyć, co blokuje co.

Główna przyczyna problemu może być również w Twoim kodzie - sprawdź POWIĄZANE funkcje, szczególnie pod kątem adnotacji, jeśli używasz JPA, jak Hibernacja.

Na przykład, jak opisano tutaj , niewłaściwe użycie następującej adnotacji może spowodować zablokowanie w bazie danych:

@Transactional(propagation = Propagation.REQUIRES_NEW) 

Zaczęło mi się to przytrafiać, gdy powiększyła się moja baza danych i wykonywałem na niej wiele transakcji.

Prawda jest taka, że prawdopodobnie istnieje jakiś sposób, aby zoptymalizować swoje zapytania lub DB, ale spróbuj tych zapytań 2 dla poprawki obejścia.

Uruchom to:

SET GLOBAL innodb_lock_wait_timeout = 5000; 

A potem to:

SET innodb_lock_wait_timeout = 5000; 

Kiedy nawiązujesz połączenie dla transakcji, nabywasz blokadę przed wykonaniem transakcji. Jeśli nie jesteś w stanie zdobyć zamka, spróbuj przez jakiś czas. Jeśli blokada nadal nie jest dostępna, wtedy zostanie wyświetlony błąd lock wait time exceeded. Dlaczego nie będziesz w stanie uzyskać blokady jest to, że nie zamykasz połączenia. Tak więc, gdy próbujesz uzyskać blokadę po raz drugi, nie będziesz w stanie uzyskać blokady, ponieważ poprzednie połączenie jest nadal zamknięte i trzyma blokadę.

Rozwiązanie: Zamknij połączenie lub setAutoCommit(true) (zgodnie z projektem), aby zwolnić blokadę.

Uruchom ponownie MySQL, działa dobrze.

Ale uważaj, że jeśli takie zapytanie utknęło, gdzieś jest problem:

• w zapytaniu (źle umieszczony znak, iloczyn kartezjański,...)
• bardzo liczne rekordy do edycji
• złożone połączenia lub testy (MD5, substraty, LIKE %...%, itd.)
• problem struktury danych
• Model klucza obcego (blokowanie łańcucha/pętli)
• błędne dane

Jak powiedział @ syedrakib, to działa, ale to nie jest długotrwałe rozwiązanie do produkcji.

Uwaga: ponowne uruchomienie może wpłynąć na Twoje dane w niespójnym stanie.

Możesz również sprawdzić, w jaki sposób MySQL obsługuje Twoje zapytanie za pomocą słowa kluczowego EXPLAIN i sprawdzić, czy coś jest możliwe, aby przyspieszyć zapytanie (indeksy, złożone testy,...).

Goto przetwarza w mysql.

Więc widać, że zadanie nadal działa.

Kill the specific process or wait until process complete.

Natknąłem się na ten sam problem z "update"-statement. Moim rozwiązaniem było po prostu uruchomienie operacji dostępnych w phpMyAdmin dla tabeli. Zoptymalizowałem, spłukałem i defragmentowałem tabelę(Nie w tej kolejności). Nie ma potrzeby, aby upuścić tabelę i przywrócić go z kopii zapasowej dla mnie. :)

Miałem ten sam problem. Myślę, że to był problem impasu z SQL. Możesz po prostu wymusić zamknięcie procesu SQL z Menedżera zadań. Jeśli to tego nie naprawiło, po prostu uruchom ponownie komputer. Nie musisz upuszczać tabeli i przeładowywać danych.

Miałem ten problem przy próbie usunięcia określonej grupy rekordów(przy użyciu MS Access 2007 z połączeniem ODBC z MySQL na serwerze WWW). Zazwyczaj chciałbym usunąć niektóre rekordy z MySQL, a następnie zastąpić zaktualizowane rekordy (kaskadowo usunąć kilka powiązanych rekordów, to usprawnia usuwanie wszystkich powiązanych rekordów dla jednego rekordu usunięcia).

Próbowałem uruchomić operacje dostępne w phpMyAdmin dla tabeli( optimize, flush, etc), ale otrzymałem potrzebne uprawnienia aby ponownie załadować błąd, gdy próbowałem spłukać. Ponieważ moja baza danych jest na serwerze internetowym, nie mogłem ponownie uruchomić bazy danych. Przywracanie z kopii zapasowej nie wchodziło w grę.

Próbowałem uruchomić zapytanie delete dla tej grupy rekordów w cPanel mySQL access w Internecie. Mam ten sam komunikat o błędzie.

Moje rozwiązanie: użyłem darmowej przeglądarki zapytań MySQL firmy Sun (Oracle) (którą wcześniej zainstalowałem na moim komputerze) i uruchomiłem tam zapytanie delete. Zadziałało od razu, Problem rozwiązany. Byłem wtedy w stanie raz ponownie wykonaj funkcję za pomocą skryptu dostępu przy użyciu ODBC dostęp do połączenia MySQL.

Problem w moim przypadku: niektóre aktualizacje zostały wprowadzone do niektórych wierszy w ramach transakcji i zanim transakcja została zatwierdzona, w innym miejscu te same wiersze były aktualizowane poza tą transakcją. Ensuring that all the updates to the rows are made within the same transaction resolved my issue.

Problem rozwiązany w moim przypadku zmieniając delete na truncate

Problem- zapytanie:

delete from Survey1.sr_survey_generic_details
mycursor.execute(query)

Fix- zapytanie:

truncate table Survey1.sr_survey_generic_details
mycursor.execute(query)

Naprawiłem to.

Upewnij się, że nie masz niedopasowanego typu danych insert w zapytaniu. Miałem problem, w którym próbowałem "dane agenta przeglądarki użytkownika" w VARCHAR(255) i miałem problem z tą blokadą, jednak gdy zmieniłem ją na {[1] } to ją naprawiłem.

Więc najprawdopodobniej jest to niedopasowanie typu danych.