Hoe vind ik welke transactie de status ‘Wachten op vergrendeling van tafelmetadata’ veroorzaakt?

Ik probeer wat DDL op een tafel uit te voeren en SHOW PROCESSLISTresulteert in het bericht “Wachten op vergrendeling van tafelmetadata”.

Hoe kom ik erachter welke transactie nog niet is afgesloten?

Ik gebruik MySQL v5.5.24.

Antwoord 1, autoriteit 100%

SHOW ENGINE INNODB STATUS \G

Zoek de sectie –

TRANSACTIONS

We kunnen INFORMATION_SCHEMAtabellen gebruiken.

Nuttige zoekopdrachten

Om te zien op welke sloten transacties wachten:

USE INFORMATION_SCHEMA;
SELECT * FROM INNODB_LOCK_WAITS;

Een lijst met blokkerende transacties:

SELECT * 
FROM INNODB_LOCKS 
WHERE LOCK_TRX_ID IN (SELECT BLOCKING_TRX_ID FROM INNODB_LOCK_WAITS);

OF

SELECT INNODB_LOCKS.* 
FROM INNODB_LOCKS
JOIN INNODB_LOCK_WAITS
  ON (INNODB_LOCKS.LOCK_TRX_ID = INNODB_LOCK_WAITS.BLOCKING_TRX_ID);

Een lijst met sloten op een bepaalde tafel:

SELECT * FROM INNODB_LOCKS 
WHERE LOCK_TABLE = db_name.table_name;

Een lijst met transacties die wachten op vergrendelingen:

SELECT TRX_ID, TRX_REQUESTED_LOCK_ID, TRX_MYSQL_THREAD_ID, TRX_QUERY
FROM INNODB_TRX
WHERE TRX_STATE = 'LOCK WAIT';

Referentie– MySQL-probleemoplossing: wat te doen als query’s worden uitgeschakeld ‘t Werkt, Hoofdstuk 6 – Pagina 96.

Antwoord 2, autoriteit 36%

Als je het proces dat de tabel vergrendelt niet kunt vinden (omdat deze al dood is), kan het zijn dat een thread nog steeds op deze manier aan het opruimen is

sectie TRANSACTIE van

show engine innodb status;

aan het einde

---TRANSACTION 1135701157, ACTIVE 6768 sec
MySQL thread id 5208136, OS thread handle 0x7f2982e91700, query id 882213399 xxxIPxxx 82.235.36.49 my_user cleaning up

zoals vermeld in een opmerking in
Transactiedeadlock wissen?

je kunt proberen de transactiethread direct te doden,
hier met

KILL 5208136;

werkte voor mij.

Antwoord 3, autoriteit 9%

mysql 5.7 onthult vergrendelingsinformatie van metadata via de tabel performance_schema.metadata_locks.

Documentatie hier

Antwoord 4, autoriteit 4%

Ik had een soortgelijk probleem met Datagrip en geen van deze oplossingen werkte.

Toen ik de Datgrip Client opnieuw opstartte, was het geen probleem meer en kon ik tabellen weer laten vallen.

Antwoord 5

Ik had net dit probleem en geen van de bovenstaande vragen toonde een vergrendeling.
Maar ik had een alter vergrendeld met dit bericht “Wachten op vergrendeling van tabelmetadata”.
Ik ontdekte dat er een langlopende query was (deze was meer dan twee uur actief). Ik heb die vraag uitgeschakeld en het alter ontgrendeld onmiddellijk.

Antwoord 6

Voor MySQL-versie >= 5.7.3geeft het prestatieschema nu metadatavergrendelingsinformatie weer.
https://dev.mysql. com/doc/relnotes/mysql/5.7/en/news-5-7-3.html

Voer deze zoekopdracht uit om te weten wie uw metadatavergrendelingen heeft

SELECT OBJECT_TYPE,
       OBJECT_SCHEMA,
       OBJECT_NAME,
       LOCK_TYPE,
       LOCK_STATUS,
       THREAD_ID,
       PROCESSLIST_ID,
       PROCESSLIST_INFO
FROM performance_schema.metadata_locks
INNER JOIN performance_schema.threads ON THREAD_ID = OWNER_THREAD_ID
WHERE PROCESSLIST_ID <> CONNECTION_ID();

Toen ik probeerde de zoekopdracht in het geaccepteerde antwoord uit te voeren, kreeg ik dit:

Empty set, 1 warning (0.001 sec)

Toen ik die ene waarschuwing controleerde, ontdekte ik dat INNODB_LOCK_WAITSverouderd is.

MySQL [ebdb]> SHOW WARNINGS;
+---------+------+-----------------------------------------------------------------------------------------------+
| Level   | Code | Message                                                                                       |
+---------+------+-----------------------------------------------------------------------------------------------+
| Warning | 1681 | 'INFORMATION_SCHEMA.INNODB_LOCK_WAITS' is deprecated and will be removed in a future release. |
+---------+------+-----------------------------------------------------------------------------------------------+