"테이블 메타데이터 잠금 대기" 상태의 원인이 되고 있는 트랜잭션을 확인하려면 어떻게 해야 합니까?

"테이블 메타데이터 잠금 대기" 상태의 원인이 되고 있는 트랜잭션을 확인하려면 어떻게 해야 합니까?

을 실행하려고 .SHOW PROCESSLISTWaiting for table metadata lock (테이블 메타데이터 잠금 대기 중)

어떤 거래가 아직 마감되지 않았는지 어떻게 알 수 있나요?

MySQL v5.5.24를 사용하고 있습니다.

MySql 버전 < 5.7.3에서 동작합니다.

SHOW ENGINE INNODB STATUS \G

섹션을 찾습니다.

TRANSACTIONS

INFORMATION_SCHEMA 테이블을 사용할 수 있습니다.

유용한 쿼리

트랜잭션이 대기 중인 모든 잠금을 확인하려면:

USE INFORMATION_SCHEMA;
SELECT * FROM INNODB_LOCK_WAITS;

차단 트랜잭션 목록:

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

또는

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

:

SELECT * FROM INNODB_LOCKS 
WHERE LOCK_TABLE = db_name.table_name;

목록:

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

레퍼런스 - MySQL 트러블 슈팅: 쿼리가 작동하지 않을 때 수행할 작업, 6장 - 96페이지.

테이블이 잠겨 있는 프로세스를 찾을 수 없는 경우(늘 데드 상태이기 때문에), 이렇게 청소하고 있는 스레드일 수 있습니다.

섹션 트랜잭션

show engine innodb status;

마지막에

---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

거래 교착 상태를 해소하기 위한 코멘트에서 언급된 바와 같이요?

트랜잭션 스레드를 직접 종료할 수 있습니다.여기서

 KILL 5208136;

날 위해 일했어

5.은 mysql 5.7을 통해 잠금 합니다.performance_schema.metadata_lockstable.syslog를 클릭합니다.

매뉴얼은 이쪽

Datagrip에서도 비슷한 문제가 발생했지만 이러한 솔루션은 모두 작동하지 않았습니다.

일단 Datagrip 클라이언트를 재시작하면 더 이상 문제가 되지 않고 테이블을 다시 드롭할 수 있습니다.

버전 > = MySQL 버전 > = MySQL 버전 > = MySQL >5.7.3이제 성능 스키마에 메타데이터 잠금 정보가 표시됩니다.https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-3.html

메타데이터 잠금을 보유한 사용자를 확인하려면 이 쿼리를 실행하십시오.

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();

---

수락된 답변으로 쿼리를 실행하려고 했을 때 다음과 같은 메시지가 수신되었습니다.

Empty set, 1 warning (0.001 sec)

의 경고를 한 결과, 「1」이라고 하는 을 알 수 있었습니다.INNODB_LOCK_WAITS을 사용하다

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

방금 이 문제가 발생했는데 위의 어떤 질문에도 잠금이 표시되지 않았습니다.하지만 이 "Waiting for table metadata lock" 메시지가 표시된 변경사항이 잠겨 있었습니다.장시간 실행 중인 쿼리가 있음을 발견했습니다(2시간 이상 실행 중).내가 그 질문을 죽였고 바로 다른 질문도 열었어.

Mysql 5.6에서는 이 답변들 중 어느 것도 완전히 통하지 않았습니다.프로세스 목록에 표시되지 않는 트랜잭션을 잠그기 위해

SHOW ENGINE INNODB STATUS \G

★★★★★★★★★★★★★★★★★★★Transactions른른른의 맨 은 너무 않은 .

---TRANSACTION 1746333130055, ACTIVE 20 sec
MySQL thread id 2078245871, OS thread handle 0x7fb1ab3bb700, query id 64608927411 10.0.200.123 app_user
Trx read view will not see trx with id >= 1746333130056, sees < 1746332958368

하지만 가끔은 그게 더 비슷해 보일 수도 있어

---TRANSACTION 1742251019746, ACTIVE 283392 sec
230145 lock struct(s), heap size 29685288, 1531889 row lock(s), undo log entries 1527774
MySQL thread id 1891102408, OS thread handle 0x7f7d8c132700, query id 59116541146 10.0.200.224 app_user
Trx read view will not see trx with id >= 1742251019747, sees < 1742250438378

^ 주의:283392 sec이 트랜잭션이 잠긴 테이블의 원인임을 나타냅니다.연관된 프로세스는 "스레드 ID"로 라벨이 지정됩니다.이거는1891102408이 경우는,이 프로세스로 인해 잠긴 원인이 무엇인지 근본 원인을 찾기 위해 db 서버의 명령줄에서 실행합니다.

mysql -u root -e 'show processlist' | grep "1891102408"

이것은 쿼리가 발신된 서버를 일의 식별자(포트 번호)와 함께 다음과 같이 나타냅니다.

32907376794 app_user    10.0.200.224:46092  production_database Sleep   124144      NULL    0   1

10.0.200.224 서버에 로그인하면,netstat -apN | grep 46092서버상의 어떤 프로세스가 Mysql 프로세스를 담당하고 있는지 확인하고 그 프로세스에서 프로세스를 종료합니다.필요한 범위까지 무엇이 잘못되었는지를 디버깅합니다.

언급URL : https://stackoverflow.com/questions/13148630/how-do-i-find-which-transaction-is-causing-a-waiting-for-table-metadata-lock-s