[MySQL] Performance Schema 모니터링 테이블 - Wait Event 및 Lock 테이블

■ Wait Event 테이블 종류

Performance schema에서 대기(waits) 도구는 시간이 걸리는 이벤트를 보여줍니다. 이벤트 계층 구조 내에서, 대기 이벤트는 스테이지(Stage) 이벤트, 명령문(Statement) 이벤트, 트랜잭션(Transaction) 이벤트와 같은 레벨의 이벤트입니다. 

 

• 설정방법

mysql> SELECT * FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/%';
+----------------------------------------+---------+-------+
| NAME                                   | ENABLED | TIMED |
+----------------------------------------+---------+-------+
| wait/io/file/innodb/innodb_data_file   | YES     | YES   |
| wait/io/file/innodb/innodb_log_file    | YES     | YES   |
| wait/io/file/innodb/innodb_temp_file   | YES     | YES   |
.....
| wait/io/socket/sql/server_tcpip_socket | NO      | NO    |
| wait/io/socket/sql/server_unix_socket  | NO      | NO    |
| wait/io/socket/sql/client_connection   | NO      | NO    |
+----------------------------------------+---------+-------+

다음과 같은 계측기들이 있습니다. 원하는 계측기에 ENABLED 컬럼을 YES, 타이머 정보까지 원한다면 TIMED컬럼을 YES로 변경합니다.

 

mysql> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE 'events_waits%';
+---------------------------+---------+
| NAME                      | ENABLED |
+---------------------------+---------+
| events_waits_current      | NO      |
| events_waits_history      | NO      |
| events_waits_history_long | NO      |
+---------------------------+---------+

컨슈머 테이블에서 해당 statement 이벤트를 YES로 변경합니다.

 

mysql> SELECT *
       FROM performance_schema.setup_timers
       WHERE NAME = 'wait';
+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE      |
+------+------------+

wait 타이머에 대해 TIMER_NAME을 원하는 시간단위로 변경합니다.

 

 

▶︎ events_waits_current

각 스레드에 대한 현재 대기 이벤트.

events_waits_current 테이블에는 현재 대기 이벤트가 포함됩니다. 테이블은 스레드의 가장 최근 모니터링 된 대기 이벤트의 현재 상태를 보여주는 스레드 당 하나의 행을 저장하므로 테이블 크기를 구성하기위한 시스템 변수가 없습니다.

 

대기 이벤트 행을 포함하는 테이블 중에서 events_waits_current가 가장 기본입니다. 대기 이벤트 행을 포함하는 다른 테이블은 현재 이벤트에서 논리적으로 파생됩니다. 예를 들어 events_waits_history 및 events_waits_history_long 테이블은 각각 스레드 당 최대 행 수까지, 그리고 모든 스레드에서 전역 적으로 종료된 가장 최근 대기 이벤트의 모음입니다.

 

+ 주요 컬럼 :

- THREAD_ID, EVENT_ID

이벤트와 연관된 스레드 및 이벤트가 시작될 때 스레드 현재 이벤트 번호. 함께 취해진 THREAD_ID 및 EVENT_ID 값은 행을 고유하게 식별합니다. 두 행에 동일한 값 쌍이 없습니다.

 

- END_EVENT_ID

이 열은 이벤트가 시작될 때 NULL로 설정되고 이벤트가 종료 될 때 스레드 현재 이벤트 번호로 업데이트됩니다.

 

- EVENT_NAME

이벤트를 생성 한 도구의 이름입니다. 이것은 setup_instruments 테이블의 NAME 값입니다. 계측기 이름은 24.6 절.“성능 스키마 계측기 명명 규칙”에서 논의 된 것처럼 여러 부분으로 구성되어 계층을 형성 할 수 있습니다.

 

- SOURCE

이벤트를 생성 한 계측 된 코드가 포함 된 소스 파일의 이름과 계측이 발생한 파일의 줄 번호입니다. 이를 통해 소스를 확인하여 관련된 코드를 정확히 확인할 수 있습니다. 예를 들어 뮤텍스 또는 잠금이 차단 된 경우 이러한 상황이 발생하는 컨텍스트를 확인할 수 있습니다.

 

- TIMER_START, TIMER_END, TIMER_WAIT

이벤트 타이밍 정보. 이 값의 단위는 피코 초 (1 조분의 1 초)입니다. TIMER_START 및 TIMER_END 값은 이벤트 타이밍이 시작되고 종료 된시기를 나타냅니다. TIMER_WAIT는 이벤트 경과 시간 (기간)입니다.

이벤트가 완료되지 않은 경우 TIMER_END는 현재 타이머 값이고 TIMER_WAIT는 지금까지 경과 한 시간입니다 (TIMER_END-TIMER_START).

TIMED = NO 인 계측기에서 이벤트가 생성되면 타이밍 정보가 수집되지 않고 TIMER_START, TIMER_END 및 TIMER_WAIT는 모두 NULL입니다.

 

- SPIN

뮤텍스의 경우 스핀 라운드 수입니다. 값이 NULL이면 코드에서 회전 라운드를 사용하지 않거나 회전이 계측되지 않습니다.

 

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE, OBJECT_INSTANCE_BEGIN

이 컬럼은 동작중인 개체를 식별합니다. 그것이 의미하는 바는 객체 유형에 따라 다릅니다.

동기화 개체 (cond, mutex, rwlock)의 경우 :

1. OBJECT_SCHEMA, OBJECT_NAME 및 OBJECT_TYPE이 NULL입니다.

2. OBJECT_INSTANCE_BEGIN은 메모리에있는 동기화 개체의 주소입니다.

 

파일 I / O 개체의 경우 :

1. OBJECT_SCHEMA가 NULL입니다.

2. OBJECT_NAME은 파일 이름입니다.

3. OBJECT_TYPE은 FILE입니다.

4. OBJECT_INSTANCE_BEGIN은 메모리의 주소입니다.

 

소켓 객체의 경우 :

1. OBJECT_NAME은 소켓의 IP : PORT 값입니다.

2. OBJECT_INSTANCE_BEGIN은 메모리의 주소입니다.

 

테이블 I / O 객체의 경우 :

1. OBJECT_SCHEMA는 테이블을 포함하는 스키마의 이름입니다.

2. OBJECT_NAME은 테이블 이름입니다.

3. OBJECT_TYPE은 지속적 기본 테이블의 경우 TABLE이고 임시 테이블의 경우 TEMPORARY TABLE입니다.

4. OBJECT_INSTANCE_BEGIN은 메모리의 주소입니다.

 

OBJECT_INSTANCE_BEGIN 값 자체는 다른 값이 다른 개체를 나타내는 것을 제외하고는 의미가 없습니다. OBJECT_INSTANCE_BEGIN은 디버깅에 사용할 수 있습니다. 예를 들어 GROUP BY OBJECT_INSTANCE_BEGIN과 함께 사용하여 1,000 개의 뮤텍스 (예 : 1,000 페이지 또는 데이터 블록 보호)에 대한로드가 균등하게 분산되어 있는지 아니면 몇 가지 병목 현상이 발생하는지 확인할 수 있습니다. 이렇게하면 로그 파일이나 다른 디버깅 또는 성능 도구에서 동일한 개체 주소를 볼 경우 다른 정보 소스와의 상관 관계를 파악할 수 있습니다.

 

- INDEX_NAME

사용 된 색인의 이름입니다. PRIMARY는 테이블 기본 인덱스를 나타냅니다. NULL은 인덱스가 사용되지 않았 음을 의미합니다.

 

- NESTING_EVENT_ID

이 이벤트가 중첩되는 이벤트의 EVENT_ID 값입니다.

 

- NESTING_EVENT_TYPE

중첩 이벤트 유형입니다. 값은 TRANSACTION, STATEMENT, STAGE 또는 WAIT입니다.

 

- OPERATION

수행 된 작업 유형 (예 : 잠금, 읽기 또는 쓰기)입니다.

 

- NUMBER_OF_BYTES

작업에서 읽거나 쓴 바이트 수입니다. 테이블 I/O 대기(wait/io/table/sql/handler 계기에 대한 이벤트)의 경우 NUMBER_OF_BYTES는 행 수를 나타냅니다.

값이 1보다 크면 이벤트는 일괄 I / O 작업에 대한 것입니다. 다음 설명에서는 단독 행보고와 일괄 I/O를 반영하는보고의 차이점에 대해 설명합니다.

 

MySQL은 중첩 루프 구현을 사용하여 조인을 실행합니다. 성능 스키마 인스 트루먼 테이션의 역할은 조인에서 테이블당 행수와 누적 실행 시간을 제공하는 것입니다.

테이블 조인 순서 t1, t2, t3을 사용하여 실행되는 다음 형식의 조인 쿼리를 가정합니다.

SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...

 

테이블 fanout(팬 아웃)은 조인 처리 중 테이블 추가로 인한 행 수의 증가 또는 감소입니다. 테이블 t3의 팬 아웃이 1보다 크면 대부분의 행 페치 작업은 해당 테이블에 대한 것입니다.

조인이 t1에서 10 행, t1에서 행당 t2에서 20행, 테이블 t2의 행당 t3에서 30행에 액세스 한다고 가정합니다. 단일 행보고를 사용하는 경우 계측된 총 작업 수는 다음과 같습니다.

10 + (10 * 20) + (10 * 20 * 30) = 6210

 

계측된 작업의 수를 크게 줄일 수 있는 것은 스캔당(즉, t1 및 t2의 고유한 행 조합당) 집계를 통해 달성할 수 있습니다. 일괄 I/O보고를 사용하면 성능 스키마는 각 행이 아닌 가장 안쪽 테이블 t3의 각 스캔에 대해 이벤트를 생성하며 계측된 행 작업의 수는 다음과 같이 감소합니다.

10 + (10 * 20) + (10 * 20) = 410

 

이는 93%의 감소로, 일괄보고 전략이 보고 호출 수를 줄여 테이블 I/O에 대한 성능 스키마 오버 헤드를 크게 줄이는 방법을 보여줍니다. 트레이드 오프는 이벤트 타이밍에 대한 정확도가 떨어집니다.

행별 보고에서와 같이 개별 행 작업에 대한 시간이 아니라 일괄 I/O 타이밍에는 조인 버퍼링, 집계 및 클라이언트에 행 반환과 같은 작업에 소요된 시간이 포함됩니다.

 

배치 I/O보고가 발생하려면 다음 조건이 충족되어야합니다.

1. 쿼리 실행은 쿼리 블록의 가장 안쪽 테이블에 액세스합니다 (단일 테이블 쿼리의 경우 해당 테이블이 가장 안쪽으로 계산 됨).

2. 쿼리 실행은 테이블에서 단일 행을 요청하지 않습니다 (예 : eq_ref 액세스는 일괄보고 사용을 방지 함).

3. 쿼리 실행은 테이블에 대한 테이블 액세스를 포함하는 하위 쿼리를 평가하지 않습니다.

 

- FLAG

향후 사용을 위해 예약되었습니다.

 

계측기(setup_instruments 테이블)에서 설정한 계측기와 관련이 있습니다.

EVENT_NAME 컬럼에 계측기 이름이 나타납니다.

 

• Tuncate Table 허용 여부

events_waits_current 테이블에는 TRUNCATE TABLE이 허용됩니다. 행을 제거합니다.

 

 

 

▶︎ events_waits_history : 스레드 당 종료 된 가장 최근 대기 이벤트.

events_waits_history 테이블에는 스레드당 종료된 N개의 최근 대기 이벤트가 포함됩니다. 대기 이벤트는 종료될 때까지 테이블에 추가되지 않습니다.

테이블에 주어진 스레드에 대한 최대 행 수가 포함된 경우 해당 스레드에 대한 새 행이 추가될 때 가장 오래된 스레드 행이 삭제됩니다. 스레드가 종료되면 모든 행이 삭제됩니다.

성능 스키마는 서버 시작 중에 N값을 자동으로 조정합니다. 스레드당 행 수를 명시적으로 설정하려면 서버 시작시 performance_schema_events_waits_history_size 시스템 변수를 설정합니다.

events_waits_history 테이블에 TRUNCATE TABLE이 허용됩니다.

 

▶︎ events_waits_history_long : 전역 적으로 (모든 스레드에서) 종료 된 가장 최근 대기 이벤트.

events_waits_history_long 테이블에는 모든 스레드에서 전역 적으로 종료 된 N 개의 가장 최근 대기 이벤트가 포함됩니다.

대기 이벤트는 종료될 때까지 테이블에 추가되지 않습니다. 테이블이 가득 차면 어느 스레드가 어느 행을 생성했는지에 관계없이 새 행이 추가될 때 가장 오래된 행이 삭제됩니다.

성능 스키마는 서버 시작 중에 N 값을 자동으로 조정합니다. 테이블 크기를 명시 적으로 설정하려면 서버 시작시 performance_schema_events_waits_history_long_size 시스템 변수를 설정합니다.

 

▶︎ Wait Event Summary 테이블

성능 스키마는 현재 및 최근 대기 이벤트를 수집하기위한 테이블을 유지하고 해당 정보를 요약 테이블에 집계합니다.

 

대기 이벤트 요약 정보의 예 :

mysql> SELECT *
       FROM performance_schema.events_waits_summary_global_by_event_name\G
...
*************************** 6. row ***************************
    EVENT_NAME: wait/synch/mutex/sql/BINARY_LOG::LOCK_index
    COUNT_STAR: 8
SUM_TIMER_WAIT: 2119302
MIN_TIMER_WAIT: 196092
AVG_TIMER_WAIT: 264912
MAX_TIMER_WAIT: 569421
...
*************************** 9. row ***************************
    EVENT_NAME: wait/synch/mutex/sql/hash_filo::lock
    COUNT_STAR: 69
SUM_TIMER_WAIT: 16848828
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 244185
MAX_TIMER_WAIT: 735345
...

 

각 대기 이벤트 요약 테이블에는 테이블이 이벤트를 집계하는 방법을 나타내는 하나 이상의 그룹화 컬럼이 있습니다. 이벤트 이름은 setup_instruments 테이블의 이벤트 장비 이름을 참조합니다.

- events_waits_summary_by_account_by_event_name에는 EVENT_NAME, USER 및 HOST 열이 있습니다. 각 행은 지정된 계정 (사용자 및 호스트 조합) 및 이벤트 이름에 대한 이벤트를 요약합니다.

- events_waits_summary_by_host_by_event_name에는 EVENT_NAME 및 HOST 열이 있습니다. 각 행은 지정된 호스트 및 이벤트 이름에 대한 이벤트를 요약합니다.

- events_waits_summary_by_instance에는 EVENT_NAME 및 OBJECT_INSTANCE_BEGIN 열이 있습니다. 각 행은 주어진 이벤트 이름 및 개체에 대한 이벤트를 요약합니다. 계측기를 사용하여 여러 인스턴스를 만드는 경우 각 인스턴스는 고유 한 OBJECT_INSTANCE_BEGIN 값을 가지며이 표에 별도로 요약됩니다.

- events_waits_summary_by_thread_by_event_name에는 THREAD_ID 및 EVENT_NAME 열이 있습니다. 각 행은 주어진 스레드 및 이벤트 이름에 대한 이벤트를 요약합니다.

- events_waits_summary_by_user_by_event_name에는 EVENT_NAME 및 USER 컬럼이 있습니다. 각 행은 주어진 사용자 및 이벤트 이름에 대한 이벤트를 요약합니다.

- events_waits_summary_global_by_event_name에는 EVENT_NAME 컬럼이 있습니다. 각 행은 주어진 이벤트 이름에 대한 이벤트를 요약합니다. 계측기는 계측 된 개체의 여러 인스턴스를 만드는 데 사용할 수 있습니다. 예를 들어 각 연결에 대해 생성 된 뮤텍스에 대한 계측기가있는 경우 연결 수만큼 인스턴스가 있습니다. 상품의 요약 행은 이러한 모든 인스턴스를 요약합니다.

 

각 wait event summary table(대기 이벤트 요약 테이블)에는 집계된 값이 포함된 다음 요약 컬럼이 있습니다.

- COUNT_STAR

요약 된 이벤트 수입니다. 이 값에는 시간 지정 여부에 관계없이 모든 이벤트가 포함됩니다.

 

- SUM_TIMER_WAIT

요약 된 시간 이벤트의 총 대기 시간입니다. 시간이 지정되지 않은 이벤트의 대기 시간은 NULL이므로이 값은 시간 지정 이벤트에 대해서만 계산됩니다. 다른 xxx_TIMER_WAIT 값도 마찬가지입니다.

 

- MIN_TIMER_WAIT

요약 된 시간 이벤트의 최소 대기 시간입니다.

 

- AVG_TIMER_WAIT

요약 된 시간 이벤트의 평균 대기 시간입니다.

 

- MAX_TIMER_WAIT

요약 된 시간 이벤트의 최대 대기 시간입니다.

 

• Tuncate Table 허용 여부

TRUNCATE TABLE은 Wait Event Summary 테이블에 허용됩니다. 다음과 같은 효과가 있습니다.

1. 계정, 호스트 또는 사용자별로 집계되지 않은 요약 테이블의 경우 잘림은 행을 제거하지 않고 요약 컬럼을 0으로 재설정합니다.

2. 계정, 호스트 또는 사용자별로 집계 된 요약 테이블의 경우 잘림은 연결이없는 계정, 호스트 또는 사용자에 대한 행을 제거하고 나머지 행에 대해 요약 컬럼을 0으로 재설정합니다.

또한 계정, 호스트, 사용자 또는 스레드별로 집계된 각 대기 요약 테이블은 종속된 연결 테이블의 절단 또는 events_waits_summary_global_by_event_name의 절단에 의해 내재적으로 절단됩니다.

 

▶︎ Object Wait Summary 테이블

성능 스키마는 개체 대기 이벤트를 집계하기 위해 objects_summary_global_by_type 테이블을 유지합니다.

 

예제 개체 대기 이벤트 요약 정보 :

mysql> SELECT * FROM performance_schema.objects_summary_global_by_type\G
...
*************************** 3. row ***************************
   OBJECT_TYPE: TABLE
 OBJECT_SCHEMA: test
   OBJECT_NAME: t
    COUNT_STAR: 3
SUM_TIMER_WAIT: 263126976
MIN_TIMER_WAIT: 1522272
AVG_TIMER_WAIT: 87708678
MAX_TIMER_WAIT: 258428280
...
*************************** 10. row ***************************
   OBJECT_TYPE: TABLE
 OBJECT_SCHEMA: mysql
   OBJECT_NAME: user
    COUNT_STAR: 14
SUM_TIMER_WAIT: 365567592
MIN_TIMER_WAIT: 1141704
AVG_TIMER_WAIT: 26111769
MAX_TIMER_WAIT: 334783032
...

 

objects_summary_global_by_type 테이블에는 테이블이 이벤트를 집계하는 방법을 나타내는 OBJECT_TYPE, OBJECT_SCHEMA 및 OBJECT_NAME 그룹화 컬럼이 있습니다. 각 행은 주어진 객체에 대한 이벤트를 요약합니다.

objects_summary_global_by_type에는 events_waits_summary_by_xxx 테이블과 동일한 요약 컬럼이 있습니다.

 

• Tuncate Table 허용 여부

TRUNCATE TABLE은 오브젝트 요약 테이블에 허용됩니다. 행을 제거하지 않고 요약 컬럼을 0으로 재설정합니다.

 

■ Lock 테이블

▶︎ metadata_locks 테이블

MySQL은 메타 데이터 잠금을 사용하여 데이터베이스 개체에 대한 동시 액세스를 관리하고 데이터 일관성을 보장합니다. 메타 데이터 잠금은 테이블뿐만 아니라 스키마, 저장된 프로그램(프로 시저, 함수, 트리거, 예약 된 이벤트),

테이블 스페이스, GET_LOCK()함수로 획득한 사용자 잠금 및 시스템 잠금에도 적용됩니다.

 

성능 스키마는 metadata_locks 테이블을 통해 메타 데이터 잠금 정보를 노출합니다.

- 부여된(granted)잠금.(현재 메타 데이터 잠금을 소유 한 세션 표시)

- 요청되었지만 아직 부여되지(granted)않은 잠금.(어떤 세션이 어떤 메타 데이터 잠금을 기다리고 있는지 표시)

- 교착 상태 감지기에 의해 종료된 잠금 요청입니다.

- 시간이 초과되어 요청 세션의 잠금 요청이 삭제되기를 기다리는 잠금 요청입니다.

 

이 정보를 통해 세션 간의 메타 데이터 잠금 종속성을 이해할 수 있습니다. 세션이 대기중인 잠금뿐만 아니라 현재 해당 잠금을 보유한 세션도 확인할 수 있습니다.

metadata_locks 테이블은 읽기 전용이며 업데이트할 수 없습니다. 기본적으로 크기가 자동으로 조정됩니다. 테이블 크기를 구성하려면 서버 시작시 performance_schema_max_metadata_locks 시스템 변수를 설정합니다.

 

메타 데이터 잠금 계측은 기본적으로 비활성화되어있는 wait/lock/metadata/sql/mdl 계측기를 사용합니다.

 

+ 설정방법

mysql> select *
       from performance_schema.setup_instruments
       WHERE NAME = 'wait/lock/metadata/sql/mdl';
+----------------------------+---------+-------+
| NAME                       | ENABLED | TIMED |
+----------------------------+---------+-------+
| wait/lock/metadata/sql/mdl | NO      | NO    |
+----------------------------+---------+-------+
1 row in set (0.00 sec)

다음과 같은 계측기가 있습니다. 원하는 계측기에 ENABLED 컬럼을 YES, 타이머 정보까지 원한다면 TIMED컬럼을 YES로 변경합니다.

 

 

성능 스키마는 각 잠금의 상태를 표시하기 위해 LOCK_STATUS 컬럼을 사용하여 다음과 같이 metadata_locks 테이블 컨텐츠를 유지합니다.

- 메타 데이터 잠금이 요청되고 즉시 획득되면 GRANTED 상태의 행이 삽입됩니다.

- 메타 데이터 잠금이 요청되었지만 즉시 확보되지 않으면 PENDING 상태의 행이 삽입됩니다.

- 이전에 요청 된 메타 데이터 잠금이 부여되면 해당 행 상태가 GRANTED로 업데이트됩니다.

- 메타 데이터 잠금이 해제되면 해당 행이 삭제됩니다.

- 교착 상태 (ER_LOCK_DEADLOCK)를 해제하기 위해 교착 상태 감지기가 보류중인 잠금 요청을 취소하면 행 상태가 PENDING에서 VICTIM으로 업데이트됩니다.

- 보류중인 잠금 요청이 시간 초과되면 (ER_LOCK_WAIT_TIMEOUT) 행 상태가 PENDING에서 TIMEOUT으로 업데이트됩니다.

- 부여된 잠금 또는 보류중인 잠금 요청이 종료되면 해당 행 상태가 GRANTED 또는 PENDING에서 KILLED로 업데이트됩니다.

- VICTIM, TIMEOUT 및 KILLED 상태 값은 간단하며 잠금 행이 삭제 될 예정임을 나타냅니다.

- PRE_ACQUIRE_NOTIFY 및 POST_RELEASE_NOTIFY 상태 값은 간단하며 메타 데이터 잠금 하위 시스템이 잠금 획득 작업을 시작하거나 잠금 해제 작업을 종료하는 동안 관심있는 스토리지 엔진에 알림을 보내고 있음을 나타냅니다. 이러한 상태 값은 MySQL 5.7.11에서 추가되었습니다.

 

+ 주요컬럼

- OBJECT_TYPE

메타 데이터 잠금 하위 시스템에서 사용되는 잠금 유형입니다. 값은 GLOBAL, SCHEMA, TABLE, FUNCTION, PROCEDURE, TRIGGER (현재 사용되지 않음), EVENT, COMMIT, USER LEVEL LOCK, TABLESPACE 또는 LOCKING SERVICE 중 하나입니다.

USER LEVEL LOCK 값은 GET_LOCK ()으로 획득 한 잠금을 나타냅니다. LOCKING SERVICE의 값은 5.5.6.1 절“잠금 서비스”에 설명 된 잠금 서비스로 획득 한 잠금을 나타냅니다.

 

- OBJECT_SCHEMA

개체를 포함하는 스키마입니다.

 

- OBJECT_NAME

계측된 개체의 이름입니다.

 

- OBJECT_INSTANCE_BEGIN

계측된 개체의 메모리 주소입니다.

 

- LOCK_TYPE

메타 데이터 잠금 하위 시스템의 잠금 유형입니다. 값은 INTENTION_EXCLUSIVE, SHARED, SHARED_HIGH_PRIO, SHARED_READ, SHARED_WRITE, SHARED_UPGRADABLE, SHARED_NO_WRITE, SHARED_NO_READ_WRITE 또는 EXCLUSIVE 중 하나입니다.

 

- LOCK_DURATION

메타 데이터 잠금 하위 시스템의 잠금 기간입니다. 값은 STATEMENT, TRANSACTION 또는 EXPLICIT 중 하나입니다. STATEMENT 및 TRANSACTION 값은 각각 문 또는 트랜잭션 끝에서 암시 적으로 해제되는 잠금을 나타냅니다. EXPLICIT 값은 문 또는 트랜잭션 종료를 유지하고 FLUSH TABLES WITH READ LOCK으로 획득 한 전역 잠금과 같은 명시 적 작업에 의해 해제되는 잠금을 나타냅니다.

 

- LOCK_STATUS

메타 데이터 잠금 하위 시스템의 잠금 상태입니다. 값은 PENDING, GRANTED, VICTIM, TIMEOUT, KILLED, PRE_ACQUIRE_NOTIFY 또는 POST_RELEASE_NOTIFY 중 하나입니다.

성능 스키마는 앞에서 설명한대로 이러한 값을 할당합니다.

 

- SOURCE

이벤트를 생성한 계측된 코드가 포함된 소스 파일의 이름과 계측이 발생한 파일의 줄 번호입니다. 이를 통해 소스를 확인하여 관련된 코드를 정확히 확인할 수 있습니다.

 

- OWNER_THREAD_ID

메타 데이터 잠금을 요청하는 스레드입니다.

 

- OWNER_EVENT_ID

메타 데이터 잠금을 요청하는 이벤트입니다.

 

TRUNCATE TABLE은 metadata_locks 테이블에 허용되지 않습니다.

 

▶︎ table_handles 테이블

성능 스키마는 table_handles 테이블을 통해 테이블 잠금 정보를 노출하여 열린 각 테이블 핸들에 대해 현재 유효한 테이블 잠금을 표시합니다. table_handles는 테이블 잠금 계측에 의해 기록 된 내용을보고합니다. 이 정보는 서버가 열려있는 테이블 핸들, 잠금 방법 및 세션을 보여줍니다.

 

table_handles 테이블은 읽기 전용이며 업데이트 할 수 없습니다. 기본적으로 크기가 자동으로 조정됩니다. 테이블 크기를 구성하려면 서버 시작시 performance_schema_max_table_handles 시스템 변수를 설정합니다.

 

테이블 잠금 계측은 기본적으로 활성화되는 wait/lock/table/sql/handler 계측기를 사용합니다.

 

mysql> select *
       from performance_schema.setup_instruments
       WHERE NAME = 'wait/lock/table/sql/handler';
+-----------------------------+---------+-------+
| NAME                        | ENABLED | TIMED |
+-----------------------------+---------+-------+
| wait/lock/table/sql/handler | YES     | YES   |
+-----------------------------+---------+-------+
1 row in set (0.00 sec)

다음과 같은 계측기가 있습니다. 원하는 계측기에 ENABLED 컬럼을 YES, 타이머 정보까지 원한다면 TIMED컬럼을 YES로 변경합니다.

 

• 주요컬럼

- OBJECT_TYPE

테이블 핸들로 열린 테이블입니다.

 

- OBJECT_SCHEMA

개체를 포함하는 스키마입니다.

 

- OBJECT_NAME

계측된 개체의 이름입니다.

 

- OBJECT_INSTANCE_BEGIN

메모리의 테이블 핸들 주소입니다.

 

- OWNER_THREAD_ID

테이블 핸들을 소유한 스레드입니다.

 

- OWNER_EVENT_ID

테이블 핸들을 열게한 이벤트입니다.

 

- INTERNAL_LOCK

SQL 레벨에서 사용되는 테이블 잠금입니다. 값은 READ, READ WITH SHARED LOCKS, READ HIGH PRIORITY, READ NO INSERT, WRITE ALLOW WRITE, WRITE CONCURRENT INSERT, WRITE LOW PRIORITY 또는 WRITE 중 하나입니다. 이러한 잠금 유형에 대한 정보는 include / thr_lock.h 소스 파일을 참조하십시오.

 

- EXTERNAL_LOCK

스토리지 엔진 수준에서 사용되는 테이블 잠금입니다. 값은 READ EXTERNAL 또는 WRITE EXTERNAL 중 하나입니다.

 

TRUNCATE TABLE은 table_handles 테이블에 허용되지 않습니다.

 

▣ Performance Schema 목차.

[MySQL] Performance Schema 소개 및 사용방법

[MySQL] Performance Schema 소개 및 사용방법

[MySQL] Performance Schema 상태 모니터링

[MySQL] Performance Schema 상태 모니터링

[MySQL] Performance Schema 설정 테이블 - Setup 및 Instance 테이블

[MySQL] Performance Schema 설정 테이블 - Setup 및 Instance 테이블

[MySQL] Performance Schema 모니터링 테이블 - Wait Event 및 Lock 테이블

[MySQL] Performance Schema 모니터링 테이블 - Wait Event 및 Lock 테이블

[MySQL] Performance Schema 모니터링 테이블 - Stage Event 테이블

[MySQL] Performance Schema 모니터링 테이블 - Stage Event 테이블

 

[MySQL] Performance Schema 모니터링 테이블 - Statement Event 테이블

[MySQL] Performance Schema 모니터링 테이블 - Statement Event 테이블

[MySQL] Performance Schema 모니터링 테이블 - Transaction 테이블

[MySQL] Performance Schema 모니터링 테이블 - Transaction 테이블

[MySQL] Performance Schema 모니터링 테이블 - Connection 및 Connection Attribute 테이블

[MySQL] Performance Schema 모니터링 테이블 - Connection 및 Connection Attribute 테이블

[MySQL] Performance Schema 모니터링 테이블 - User, 시스템, 상태 및 기타 테이블

[MySQL] Performance Schema 모니터링 테이블 - User, 시스템, 상태 및 기타 테이블

[MySQL] Performance Schema 모니터링 테이블 - Summary(요약) 테이블

[MySQL] Performance Schema 모니터링 테이블 - Summary(요약) 테이블

[MySQL] Performance Schema 모니터링 테이블 - Replication 테이블

[MySQL] Performance Schema 모니터링 테이블 - Replication 테이블