데브러너 (DevRunner)

29.19.2 Parent Event 정보 가져오기

data_locks 테이블은 보유 및 요청된 데이터 락을 보여줍니다. 이 테이블의 row에는 락을 보유한 세션의 스레드 ID를 나타내는 THREAD_ID 컬럼과, 락을 발생시킨 Performance Schema 이벤트를 나타내는 EVENT_ID 컬럼이 있습니다. (THREAD_ID, EVENT_ID) 값의 튜플은 다른 Performance Schema 테이블에서 parent 이벤트를 묵시적으로 식별합니다:

events_waits_xxx 테이블의 parent wait 이벤트
events_stages_xxx 테이블의 parent stage 이벤트
events_statements_xxx 테이블의 parent statement 이벤트
events_transactions_current 테이블의 parent transaction 이벤트

parent 이벤트에 대한 세부 정보를 얻으려면, THREAD_ID 및 EVENT_ID 컬럼을 해당 parent 이벤트 테이블에서 같은 이름을 가진 컬럼과 조인합니다. 이 관계는 중첩 집합 데이터 모델에 기반하므로, 조인에는 여러 절이 포함됩니다. parent 및 child 테이블을 각각 parent와 child로 나타내면, 조인은 다음과 같습니다:

1WHERE
2  parent.THREAD_ID = child.THREAD_ID        /* 1 */
3  AND parent.EVENT_ID < child.EVENT_ID      /* 2 */
4  AND (
5    child.EVENT_ID <= parent.END_EVENT_ID   /* 3a */
6    OR parent.END_EVENT_ID IS NULL          /* 3b */
7  )

조인 조건은 다음과 같습니다:

parent 이벤트와 child 이벤트는 동일한 스레드에 있습니다.
child 이벤트는 parent 이벤트 이후에 시작하므로, 그 EVENT_ID 값은 parent의 값보다 큽니다.
parent 이벤트는 완료되었거나 여전히 실행 중입니다.

락 정보를 찾기 위해, data_locks는 child 이벤트를 포함하는 테이블입니다.

data_locks 테이블은 존재하는 락만을 보여주므로, 어떤 테이블이 parent 이벤트를 포함하는지와 관련하여 다음 사항이 적용됩니다:

transaction의 경우 선택지는 events_transactions_current뿐입니다. transaction이 완료되었다면 transaction history 테이블에 있을 수 있지만, 락은 이미 사라졌습니다.
statement의 경우, 락을 획득한 statement가 이미 완료된 transaction의 statement인지(이 경우 events_statements_history 사용) 또는 해당 statement가 아직 실행 중인지(이 경우 events_statements_current 사용)에 달려 있습니다.
stage의 경우, 논리는 statement와 유사합니다. events_stages_history 또는 events_stages_current를 사용합니다.
wait의 경우, 논리는 statement와 유사합니다. events_waits_history 또는 events_waits_current를 사용합니다. 그러나 너무 많은 wait이 기록되므로, 락을 발생시킨 wait은 history 테이블에서 이미 사라졌을 가능성이 매우 큽니다.

wait, stage, statement 이벤트는 history에서 빠르게 사라집니다. 오래 전에 실행된 statement가 락을 획득했지만 여전히 열려 있는 transaction에 속해 있다면, 해당 statement는 찾지 못할 수 있지만, transaction은 찾을 수 있습니다.

이 때문에 parent 이벤트를 찾는 데에는 중첩 집합 데이터 모델이 더 잘 작동합니다. parent/child 관계(데이터 락 -> parent wait -> parent stage -> parent transaction)의 링크를 따라가는 방식은 중간 노드가 이미 history 테이블에서 사라진 경우에는 잘 작동하지 않습니다.

다음 시나리오는 락이 획득된 statement의 parent transaction을 찾는 방법을 보여줍니다:

Session A:

1[1] START TRANSACTION;
2[2] SELECT * FROM t1 WHERE pk = 1;
3[3] SELECT 'Hello, world';

Session B:

1SELECT ...
2FROM performance_schema.events_transactions_current AS parent
3  INNER JOIN performance_schema.data_locks AS child
4WHERE
5  parent.THREAD_ID = child.THREAD_ID
6  AND parent.EVENT_ID < child.EVENT_ID
7  AND (
8    child.EVENT_ID <= parent.END_EVENT_ID
9    OR parent.END_EVENT_ID IS NULL
10  );

Session B의 query는 statement [2]가 pk=1인 레코드에 대한 데이터 락을 보유하고 있음을 보여주어야 합니다.

Session A가 더 많은 statement를 실행하면, [2]는 history 테이블에서 사라집니다.

이 query는 [1]에서 시작된 transaction을, 실행된 statement, stage, wait의 개수와 관계없이 보여주어야 합니다.

더 많은 데이터를 보기 위해, transaction을 제외하고, 서버에서 다른 query가 실행되지 않는다고 가정하면(history가 보존되도록), events_xxx_history_long 테이블도 사용할 수 있습니다.

29.19.2 Obtaining Parent Event Information

29.19.2 Parent Event 정보 가져오기