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

■ Performance Schema 소개

MySQL 성능 스키마는 낮은 수준에서 MySQL 서버 실행을 모니터링하는 기능입니다. 성능 스키마에는 다음과 같은 특성이 있습니다.

- 성능 스키마는 런타임에 서버의 내부 실행을 검사하는 방법을 제공합니다. PERFORMANCE_SCHEMA 스토리지 엔진 및 performance_schema 데이터베이스를 사용하여 구현됩니다.

  성능 스키마는 주로 성능 데이터에 중점을 둡니다. 이는 메타 데이터 검사에 사용되는 INFORMATION_SCHEMA와 다릅니다.

- 성능 스키마는 서버 이벤트를 모니터링합니다. "이벤트"는 시간이 걸리고 타이밍 정보를 수집 할 수 있도록 계측된 서버가 수행하는 모든 작업입니다. 일반적으로 이벤트는 함수 호출, 운영 체제 대기, 구문 분석 또는 정렬과 같은 SQL 문 실행 단계 또는 

  전체문 또는 그룹문 일 수 있습니다. 이벤트 콜렉션은 서버 및 여러 스토리지 엔진에 대한 동기화 호출 (예 : 뮤텍스) 파일 및 테이블 I/O, 테이블 잠금 등에 대한 정보에 대한 액세스를 제공합니다.

- 성능 스키마 이벤트는 서버의 바이너리 로그 (데이터 수정 사항을 설명) 및 이벤트 스케줄러 이벤트 (저장 프로그램 유형)에 기록 된 이벤트와 다릅니다.

- 성능 스키마 이벤트는 MySQL 서버의 특정 인스턴스에 따라 다릅니다. 성능 스키마 테이블은 서버에 로컬로 간주되며 변경 사항은 복제되거나 바이너리 로그에 기록되지 않습니다.

- 현재 이벤트는 물론 이벤트 기록 및 요약을 사용할 수 있습니다. 이를 통해 계측 된 활동이 수행 된 횟수와 소요 된 시간을 확인할 수 있습니다.

  이벤트 정보는 특정 스레드의 활동 또는 뮤텍스 또는 파일과 같은 특정 개체와 관련된 활동을 표시하는 데 사용할 수 있습니다.

- PERFORMANCE_SCHEMA 스토리지 엔진은 서버 소스 코드의 "계측 지점"을 사용하여 이벤트 데이터를 수집합니다.

- 수집된 이벤트는 performance_schema 데이터베이스의 테이블에 저장됩니다. 이러한 테이블은 다른 테이블과 마찬가지로 SELECT 문을 사용하여 쿼리할 수 ​​있습니다.

- 성능 스키마 구성은 SQL 문을 통해 performance_schema 데이터베이스의 테이블을 업데이트하여 동적으로 수정할 수 있습니다. 구성 변경은 데이터 수집에 즉시 영향을 미칩니다.

- 성능 스키마의 테이블은 영구 디스크 스토리지를 사용하지 않는 인 메모리 테이블입니다. 내용은 서버 시작시 다시 채워지고 서버 종료시 삭제됩니다.

- 모니터링은 MySQL에서 지원하는 모든 플랫폼에서 사용할 수 있습니다.

- 몇 가지 제한 사항이 적용될 수 있습니다. 타이머 유형은 플랫폼에 따라 다를 수 있습니다. 스토리지 엔진에 적용되는 도구는 모든 스토리지 엔진에 대해 구현되지 않을 수 있습니다. 각 타사 엔진의 계측은 엔진 유지 관리자의 책임입니다.

- 데이터 수집은 계측을 추가하기 위해 서버 소스 코드를 수정하여 구현됩니다. 복제 또는 이벤트 스케줄러와 같은 다른 기능과 달리 성능 스키마와 관련된 별도의 스레드가 없습니다.

 

성능 스키마는 서버 성능에 미치는 영향을 최소화하면서 서버 실행에 대한 유용한 정보에 대한 액세스를 제공하기위한 것입니다. 구현은 다음 디자인 목표를 따릅니다.

- 성능 스키마를 활성화해도 서버 동작은 변경되지 않습니다. 예를 들어 스레드 스케줄링이 변경되지 않으며, EXPLAIN에 표시된대로 쿼리 실행 계획이 변경되지 않습니다.

- 서버 모니터링은 오버 헤드가 거의없이 지속적이고 눈에 잘 띄지 않습니다. 성능 스키마를 활성화해도 서버를 사용할 수 없게되는 것은 아닙니다.

- 파서는 변경되지 않습니다. 새로운 키워드나 문장이 없습니다.

- 성능 스키마가 내부적으로 실패하더라도 서버 코드 실행은 정상적으로 진행됩니다.

- 초기 이벤트 수집중 처리를 수행하거나 나중에 이벤트 검색중 처리를 수행할 경우 수집 속도를 높이는 것이 우선입니다. 이는 수집이 진행중이지만 검색은 요청에 따라 이루어지며 전혀 발생하지 않을 수 있기 때문입니다.

- 새 계측 지점을 쉽게 추가 할 수 있습니다.

- 인스트루먼테이션이 버전 화됩니다. 계측 구현이 변경되면 이전에 계측된 코드가 계속 작동합니다. 최신 성능 스키마 변경 사항과 동기화 상태를 유지하기 위해 각 플러그인을 업그레이드 할 필요가 없기 때문에 타사 플러그인 개발자에게 도움이됩니다.

 

▶︎ Performance Schema 엔진 확인.

INFORMATION_SCHEMA.ENGINES테이블 혹은 SHOW ENGINES 명령어를 이용하여 Performance Schema엔진을 사용할 수 있는지 확인합니다.

mysql> SELECT * FROM INFORMATION_SCHEMA.ENGINES
       WHERE ENGINE='PERFORMANCE_SCHEMA'\G
*************************** 1. row ***************************
      ENGINE: PERFORMANCE_SCHEMA
     SUPPORT: YES
     COMMENT: Performance Schema
TRANSACTIONS: NO
          XA: NO
  SAVEPOINTS: NO

mysql> SHOW ENGINES\G
...
      Engine: PERFORMANCE_SCHEMA
     Support: YES
     Comment: Performance Schema
Transactions: NO
          XA: NO
  Savepoints: NO
...

 

▶︎ 성능 테이블의 위치.

performance_schema 스키마안에 성능관련 테이블들이 위치하고 있습니다.

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
       WHERE TABLE_SCHEMA = 'performance_schema';
+------------------------------------------------------+
| TABLE_NAME                                           |
+------------------------------------------------------+
| accounts                                             |
| cond_instances                                       |
...
| events_stages_current                                |
| events_stages_history                                |
| events_stages_history_long                           |
| events_stages_summary_by_account_by_event_name       |
| events_stages_summary_by_host_by_event_name          |
| events_stages_summary_by_thread_by_event_name        |
| events_stages_summary_by_user_by_event_name          |
| events_stages_summary_global_by_event_name           |
| events_statements_current                            |
| events_statements_history                            |
| events_statements_history_long                       |
...
| file_instances                                       |
| file_summary_by_event_name                           |
| file_summary_by_instance                             |
| host_cache                                           |
| hosts                                                |
| memory_summary_by_account_by_event_name              |
| memory_summary_by_host_by_event_name                 |
| memory_summary_by_thread_by_event_name               |
| memory_summary_by_user_by_event_name                 |
| memory_summary_global_by_event_name 
...                 |
| metadata_locks                                       |
| mutex_instances                                      |
| objects_summary_global_by_type                       |
| table_io_waits_summary_by_table                      |
| table_lock_waits_summary_by_table                    |
| threads                                              |
| users                                                |
+------------------------------------------------------+

mysql> SHOW TABLES FROM performance_schema;
+------------------------------------------------------+
| Tables_in_performance_schema                         |
+------------------------------------------------------+
| accounts                                             |
| cond_instances                                       |
| events_stages_current                                |
| events_stages_history                                |
| events_stages_history_long                           |
...

 

 

■ Performance schema(성능 스키마) 기본 설정

▶︎ 설정하기에 앞서..

Performance Schema의 메트릭을 활성화하여 원하는 부분을 모니터링 하는 방법을 설명 합니다.

생각보다 좀 복잡한게 사실입니다. 그러나 세세하게 설정을 해야하는 많큼 모니터링할 수 있는 메트릭은 정말 다양합니다.

처음 접하시는 분들은 어려운게 맞고 경험자도 쉽게 접근하기는 어렵습니다. 하지만 끈기를 가지고 끝까지 읽어 주신다면 비로서 이 성능 스키마를 정복할 수 있으시리라 생각합니다. 

 

▶︎ 전체적인 전체 설정 사이클.

1. performance schema 사용 옵션 활성화.(my.cnf)

2. performance schema 시스템 환경변수 설정.

3. 5가지 setup table 설정.

  - setup_actors

  - setup_consumers

  - setup_instruments

  - setup_objects

  - setup_timers

4. 각 이벤트 모니터링.  

 

▶︎ 시스템 변수 설정 방법

Performance Schema를 설정할 때 시스템 변수설정과 셋업 테이블 설정 2가지가 있습니다.

 

• 시스템 변수 설정.

my.cnf(서버 환경 구성 파일)에 다음 사항을 추가합니다. 기본값은 ON입니다.

[mysqld]
performance_schema=ON

 

Performance Schema에 추가적으로 설정할 파라미터는 다음 페이지에 있습니다.

https://github.com/myacelink/MySQL/blob/master/01.Server-Parameters.txt

"Performance Schema System Variables" 관련 옵션들 섹션에 있습니다.

이것을 참고하여 설정을 진행합니다.

 

참고로 Performance Schema 시스템 변수는 값이 -1이거나 특정 값을 할당하는 방식으로 되어 있습니다.

-1의 의미는 자동으로 값을 할당하거나 혹은 파라미터 속성에 따라 임의의 값으로 할당하면 안되는 값들입니다.

파라미터마다 틀리므로 자세한 내용은 위의 파라미터 링크 페이지를 참고바랍니다.

또한 성능 스키마는 서버 시작중에 모든 메모리를 할당하는 것이 아니라 점진적으로 필요할 시 할당받아 사용됩니다.

 

서버 시작시 설정되지 않은 각 자동 크기 파라미터 변수에 대해 성능 스키마는 MySQL 서버를 구성한 방법에 대해 힌트로 간주되는 다음 시스템 값의 값을 기반으로 결정합니다.

max_connections
open_files_limit
table_definition_cache
table_open_cache

주어진 매개 변수에 대한 자동 조정 또는 자동 크기 조정을 설정하려면 시작할 때 -1이 아닌 값으로 설정합니다. 이 경우 Performance schema는 지정된 값을 할당합니다.

SHOW VARIABLES는 자동 크기 조정 매개 변수가 설정된 실제 값을 표시합니다. 자동 크기로 설정된 매개 변수는 -1 값으로 표시됩니다.

 

mysql> SHOW VARIABLES LIKE 'perf%';
+--------------------------------------------------------+---------+
| Variable_name                                          | Value   |
+--------------------------------------------------------+---------+
| performance_schema                                     | ON      |
| performance_schema_accounts_size                       | 100     |
| performance_schema_digests_size                        | 200     |
| performance_schema_events_stages_history_long_size     | 10000   |
| performance_schema_events_stages_history_size          | 10      |
| performance_schema_events_statements_history_long_size | 10000   |
| performance_schema_events_statements_history_size      | 10      |
| performance_schema_events_waits_history_long_size      | 10000   |
| performance_schema_events_waits_history_size           | 10      |
| performance_schema_hosts_size                          | 100     |
| performance_schema_max_cond_classes                    | 80      |
| performance_schema_max_cond_instances                  | 1000    |
...

 

 

서버 재시작 후 다음 사항을 확인합니다.

mysql> SHOW VARIABLES LIKE 'performance_schema';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| performance_schema | ON    |
+--------------------+-------+

 

▶︎ 이벤트 타이밍 설정.

이벤트는 서버 소스 코드에 추가 된 계측을 통해 수집됩니다. 성능 스키마가 이벤트에 걸리는 시간에 대한 아이디어를 제공하는 방법인 시간 이벤트를 계측합니다.

타이밍 정보를 수집하지 않도록 계측기를 구성 할 수도 있습니다. 이 섹션에서는 사용 가능한 타이머와 해당 특성, 이벤트에서 타이밍 값이 표시되는 방식에 대해 설명합니다.

 

관련 테이블은 2가지로 분류됩니다.

- performance_timers는 사용 가능한 타이머와 그 특성을 나열합니다.

- setup_timers는 어떤 기기에 어떤 타이머가 사용되는지를 나타냅니다.

setup_actors

 

 

 

▶︎ performance_timers 테이블

mysql> select * from performance_schema.performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE       |      3098671641 |                1 |             24 |
| NANOSECOND  |      1000000000 |                1 |             48 |
| MICROSECOND |         1000000 |                1 |             48 |
| MILLISECOND |            1037 |                1 |             44 |
| TICK        |             101 |                1 |           1892 |
+-------------+-----------------+------------------+----------------+
5 rows in set (0.00 sec)

지정된 타이머 이름과 연결된 값이 NULL이면 해당 타이머가 플랫폼에서 지원되지 않습니다. NULL을 포함하지 않는 행은 setup_timers에서 사용할 수있는 타이머를 나타냅니다.

 

각 컬럼의 속성은 다음과 같습니다.

- TIMER_NAME 컬럼에는 사용 가능한 타이머의 이름이 표시됩니다. CYCLE은 CPU (프로세서)주기 카운터를 기반으로하는 타이머를 나타냅니다.

사용할 수있는 setup_timers의 타이머는 다른 컬럼에 NULL이 없는 타이머입니다. 지정된 타이머 이름과 연결된 값이 NULL이면 해당 타이머가 플랫폼에서 지원되지 않습니다.

 

- TIMER_FREQUENCY는 초당 타이머 단위 수를 나타냅니다. 주기 타이머의 경우 주파수는 일반적으로 CPU 속도와 관련이 있습니다. 표시된 값은 2.4GHz 프로세서가있는 시스템에서 얻은 것입니다.

다른 타이머는 고정된 초 단위를 기반으로합니다. TICK의 경우 빈도는 플랫폼에 따라 다를 수 있습니다 (예 : 일부는 초당 100 틱 사용, 다른 일부는 초당 1000 틱 사용).

 

- TIMER_RESOLUTION은 타이머 값이 한 번에 증가하는 타이머 단위 수를 나타냅니다. 타이머의 분해능이 10이면 값이 매번 10 씩 증가합니다.

 

- TIMER_OVERHEAD는 주어진 타이머로 하나의 타이밍을 얻기위한 최소 오버 헤드 사이클 수입니다. 이벤트의 시작과 끝에서 타이머가 호출되기 때문에 이벤트당 오버 헤드는 표시된 값의 두 배입니다.

 

▶︎ setup_timers 테이블

현재 이벤트 타이머를 설정합니다.

mysql> select * from performance_schema.setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+
5 rows in set, 1 warning (0.00 sec)

NAME 값은 타이머가 적용되는 계측기 유형을 나타내고 TIMER_NAME은 해당 기기에 적용되는 타이머를 나타냅니다. 타이머는 이름이 NAME 값과 일치하는 요소로 시작하는 기기에 적용됩니다.

 

위 setup_timers 테이블의 TIMER_NAME은 원하는 TIMER_NAME으로 바꿀 수 있습니다. SQL명령문으로 바꿉니다.

mysql> UPDATE performance_schema.setup_timers
       SET TIMER_NAME = 'MICROSECOND'
       WHERE NAME = 'idle';

참고로 가장 부하가 가장 타이머는 CYCLE입니다. 그러나 MySQL문서에서는 wait관련 이름은 CYCLE, stage-statement관련 이름은 NANOSECOND으로 하기를 권고하고 있습니다.

참고로 타이머의 사이클(1번의 수행)은 명령문이 시작될때 한번, 종료될때 한번 해서 총 2번이 한번의 사이클입니다.

 

▶︎ 이벤트에서 성능 스키마 표현

현재 이벤트 및 기록 이벤트를 저장하는 성능 스키마 테이블의 행에는 타이밍 정보를 나타내는 세 개의 컬럼이 있습니다.

TIMER_START 및 TIMER_END는 이벤트가 시작되고 종료 된시기를 나타내고 TIMER_WAIT는 이벤트 기간을 나타냅니다.

setup_instruments 테이블에는 이벤트를 수집 할 기기를 나타내는 ENABLED 컬럼이 있습니다. 또한 테이블에는 시간이 지정된 기기를 나타내는 TIMED 컬럼이 있습니다.

계측기가 활성화되지 않은 경우 이벤트를 생성하지 않습니다. 활성화 된 계측기가 시간이 지정되지 않은 경우 계측기에서 생성 된 이벤트는 TIMER_START,

TIMER_END 및 TIMER_WAIT 타이머 값에 대해 NULL을 갖습니다. 그러면 요약 테이블에서 집계 시간 값 (합계, 최소값, 최대 값 및 평균)을 계산할 때 해당 값이 무시됩니다.

 

타이머 베이스라인("time zero")은 서버 시작중 성능 스키마 초기화시 발생합니다. 이벤트의 TIMER_START 및 TIMER_END 값은 기준선 이후의 피코초를 나타냅니다.

TIMER_WAIT 값은 피코초 단위의 기간입니다.

 

setup_timers 테이블을 수정하면 모니터링에 즉시 반영됩니다. 만약 예상치 못한 결과를 방지하려면 TRUNCATE TABLE을 사용하여 성능 스키마 통계를 재설정합니다.

 

대기, 단계, 명령문 또는 트랜잭션 이벤트가 실행되는 동안 각 현재 이벤트 테이블에는 현재 이벤트 타이밍 정보가 표시됩니다.

events_waits_current
events_stages_current
events_statements_current
events_transactions_current

 

아직 완료되지 않은 이벤트가 실행된 기간을 확인할 수 있도록 타이머 컬럼은 다음과 같이 설정됩니다.

TIMER_START가 채워집니다.

TIMER_END는 현재 타이머 값으로 채워집니다.

TIMER_WAIT는 지금까지 경과 된 시간 (TIMER_END-TIMER_START)으로 채워집니다.

 

아직 완료되지 않은 이벤트의 END_EVENT_ID 값은 NULL입니다. 이벤트에 대해 지금까지 경과 한 시간을 평가하려면 TIMER_WAIT컬럼을 사용합니다.

따라서 아직 완료되지 않았고 지금까지 N 피코 초보다 오래 걸린 이벤트를 식별하기 위해 모니터링 애플리케이션은 쿼리에서 이 표현식을 사용할 수 있습니다.

WHERE END_EVENT_ID IS NULL AND TIMER_WAIT > N

참고로 위 쿼리는 해당 계측기가 ENABLED 및 TIMED가 YES로 설정되어 있고 관련 컨슈머(소비자)가 활성화되어 있다고 가정합니다.

 

■ 셋업 테이블 설정

계측기 수집 및 설정은 즉시 반영됩니다.

setup_actors 테이블에 대한 수정은 기존 스레드가 아니라 수정 이후에 생성 된 포 그라운드 스레드에만 영향을줍니다.

모니터링 구성을 변경할 때 성능 스키마는 기록 테이블을 플러시하지 않습니다. 이미 수집 된 이벤트는 최신 이벤트로 대체 될 때까지 현재 이벤트 및 기록 테이블에 남아 있습니다. 계측기를 비활성화하는 경우 해당 이벤트가 관심있는 최신 이벤트로 대체 될 때까지 잠시 기다려야 할 수 있습니다. 또는 TRUNCATE TABLE을 사용하여 히스토리 테이블을 비웁니다.

 

계측을 변경 한 후 요약 테이블을자를 수 있습니다. 일반적으로 결과는 행을 제거하는 것이 아니라 요약 컬럼을 0 또는 NULL로 재설정하는 것입니다. 이렇게하면 수집 된 값을 지우고 집계를 다시 시작할 수 있습니다. 예를 들어 런타임 구성을 변경 한 후 유용 할 수 있습니다. 이 잘림 동작에 대한 예외는 개별 요약 테이블 섹션에 설명되어 있습니다.

 

사전 필터링을 구성하려면 setup_consumers 테이블을 수정합니다. 이 테이블은 이벤트가 전송되는 대상을 결정합니다.

또한 이벤트 생성에 암시적으로 영향을줍니다. 지정된 이벤트가 대상으로 전송되지 않으면 (사용되지 않음) 성능 스키마가 이벤트를 생성하지 않습니다.

 

▶︎ setup_consumers 테이블

이벤트 정보를 보내고 저장할 수 있는 대상을 설정합니다.

mysql> SELECT * FROM performance_schema.setup_consumers;
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| events_stages_current            | NO      |
| events_stages_history            | NO      |
| events_stages_history_long       | NO      |
| events_statements_current        | YES     |
| events_statements_history        | YES     |
| events_statements_history_long   | NO      |
| events_transactions_current      | NO      |
| events_transactions_history      | NO      |
| events_transactions_history_long | NO      |
| events_waits_current             | NO      |
| events_waits_history             | NO      |
| events_waits_history_long        | NO      |
| global_instrumentation           | YES     |
| thread_instrumentation           | YES     |
| statements_digest                | YES     |
+----------------------------------+---------+

 

위 setup_consumers테이블에서 Consumer 카테고리는 다음과 같습니다.

- Global and Thread Consumers
- Wait Event Consumers
- Stage Event Consumers
- Statement Event Consumers
- Transaction Event Consumers
- Statement Digest Consumer

 

setup_consumers 테이블을 설정하여 이벤트를 생성하고 모니터링할 항목에 대해 사용여부를 나타냅니다.

설정방법은 쿼리를 이용하여 해당 항목을 업데이트 합니다. ENABLED 컬럼에서 YES면 사용, NO면 사용하지 않습니다.

해당 업데이트는 즉시 적용됩니다. 모니터링은 시스템에 부하를 주기 때문에 모니터링하지 않는 항목은 시스템NO로 바꾸어 사용을 중지합니다.

 

위의 카테고리 항목은 아래와 같이 계층형으로 표시되며 맨아래 하위 계층은 상위 계층이 활성화 되어야 모니터링 수집이 작동됩니다.

예를 들어 events_waits_history, events_waits_history_long은 상위 events_waits_current가 수집이 되어야 합니다.

I.global_instrumentation
  i.thread_instrumentation
    1.events_waits_current
      ▷.events_waits_history
      ▷.events_waits_history_long
    1.events_stages_current
      ▷.events_stages_history
      ▷.events_stages_history_long
    1.events_statements_current
      ▷.events_statements_history
      ▷.events_statements_history_long
    1.events_transactions_current
      ▷.events_transactions_history
      ▷.events_transactions_history_long
  i.statements_digest

 

global_instrumentation는 최상위의(전역) Consumer입니다. 이 Consumer가 NO이면 모든 이벤트가 수집되지 않습니다.

반드시 YES로 되어 있어야 합니다. 이 global_instrumentation이 활성화되면 thread_instrumentation또한 활성화되어야 하위 이벤트들인 events_xxx가 수집됩니다.

 

각 events_xxxx_history, events_xxxx_history_long테이블은 상위테이블인 events_xxx_current 항목이 활성화 되어야 수집이 됩니다.

 

▶︎ setup_instruments 테이블

이벤트를 수집할 수 있는 계측된 개체의 클래스입니다.

wait, stage, statement, transaction등에 관련된 여러 계측기를 설정합니다.

mysql> SELECT * FROM performance_schema.setup_instruments;
+--------------------------------------------------------------------------------+---------+-------+
| NAME                                                                           | ENABLED | TIMED |
+--------------------------------------------------------------------------------+---------+-------+
...                             
| stage/sql/end                                                                  | NO      | NO    |
| stage/sql/executing                                                            | NO      | NO    |
| stage/sql/init                                                                 | NO      | NO    |
| stage/sql/insert                                                               | NO      | NO    |
...                             
| statement/sql/load                                                             | YES     | YES   |
| statement/sql/grant                                                            | YES     | YES   |
| statement/sql/check                                                            | YES     | YES   |
| statement/sql/flush                                                            | YES     | YES   |
...                             
| wait/synch/mutex/sql/LOCK_global_read_lock                                     | YES     | YES   |
| wait/synch/mutex/sql/LOCK_global_system_variables                              | YES     | YES   |
| wait/synch/mutex/sql/LOCK_lock_db                                              | YES     | YES   |
| wait/synch/mutex/sql/LOCK_manager                                              | YES     | YES   |
...
| memory/performance_schema/events_transactions_summary_by_account_by_event_name | YES     | NO    |
| memory/performance_schema/events_transactions_summary_by_host_by_event_name    | YES     | NO    |
| memory/performance_schema/events_transactions_summary_by_thread_by_event_name  | YES     | NO    |
| memory/performance_schema/events_transactions_history                          | YES     | NO    |
| memory/performance_schema/events_transactions_summary_by_user_by_event_name    | YES     | NO    |

 

setup_instruments 테이블의 ENABLED 컬럼이 YES이면 몇몇을 제외한 해당 계측 기기를 즉시 활성화하고 모니터링 수집을 시작합니다.

대부분의 setup_instruments 행에 대한 수정 사항은 모니터링에 즉시 영향을줍니다. 그러나 일부 기기의 경우 수정은 서버 시작시에만 적용됩니다.

런타임에 변경해도 효과가 없습니다. 이는 서버의 뮤텍스, 조건 및 rwlock에 주로 영향을 미칩니다.

 

setup_instruments 테이블의 TIMED를 YES로 수정하면 위에서 설명한 이벤트 타이밍이 기록됩니다.

수정방법은 SQL문의 UPDATE를 사용하여 상태를 변경합니다.

mysql> UPDATE performance_schema.setup_instruments
       SET ENABLED = 'NO'
       WHERE NAME LIKE 'wait/io/file/%';

 

이 테이블에서 비활성화된 기기는 다른 생산 관련 설정 표의 내용에 관계없이 이벤트를 생성하지 않습니다.

이 테이블에서 활성화된 계측기는 다른 테이블의 내용에 따라 이벤트를 생성할 수 있습니다.

 

계측기가 활성화되고 실행되면 계측된 인스턴스가 생성되며 이는 file_instances 또는 rwlock_instances와 같은 xxx_instances 테이블에 표시됩니다.

 

▶︎ setup_objects 테이블

setup_objects 테이블은 performance schema가 특정 테이블 및 Stored Program 객체들 중 어떤 객체들을 모니터링할지 제어합니다.

mysql> select * from setup_objects;
+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| EVENT       | mysql              | %           | NO      | NO    |
| EVENT       | performance_schema | %           | NO      | NO    |
| EVENT       | information_schema | %           | NO      | NO    |
| EVENT       | %                  | %           | YES     | YES   |
| FUNCTION    | mysql              | %           | NO      | NO    |
| FUNCTION    | performance_schema | %           | NO      | NO    |
| FUNCTION    | information_schema | %           | NO      | NO    |
| FUNCTION    | %                  | %           | YES     | YES   |
| PROCEDURE   | mysql              | %           | NO      | NO    |
| PROCEDURE   | performance_schema | %           | NO      | NO    |
| PROCEDURE   | information_schema | %           | NO      | NO    |
| PROCEDURE   | %                  | %           | YES     | YES   |
| TABLE       | mysql              | %           | NO      | NO    |
| TABLE       | performance_schema | %           | NO      | NO    |
| TABLE       | information_schema | %           | NO      | NO    |
| TABLE       | %                  | %           | YES     | YES   |
| TRIGGER     | mysql              | %           | NO      | NO    |
| TRIGGER     | performance_schema | %           | NO      | NO    |
| TRIGGER     | information_schema | %           | NO      | NO    |
| TRIGGER     | %                  | %           | YES     | YES   |
+-------------+--------------------+-------------+---------+-------+
20 rows in set (0.00 sec)

 

위 항목에서 ENABLED컬럼을 YES로 변경 즉시 적용되며 모니터링 됩니다. TIMED를 YES로 수정하면 위에서 설명한 이벤트 타이밍이 기록됩니다.

OBJECT_TYPE 컬럼은 행이 적용되는 개체의 유형을 나타냅니다. TABLE 필터링은 테이블 I/O 이벤트(wait/io/table/sql/handler 계측기) 및

테이블 잠금 이벤트(wait/lock/table/sql/handler 계측기)에 영향을줍니다. 이 이벤트들은 setup_instruments테이블에 있습니다.

기본적으로 mysql, performance_schema, information_schema는 계측하지 않습니다.

 

테이블 관련 이벤트의 경우 성능 스키마는 setup_objects의 내용을 setup_instruments와 결합하여 계측기를 활성화할지 여부와 활성화 계측기 시간을 결정할 것인지 결정합니다.

- setup_objects의 행과 일치하는 테이블의 경우 테이블 계측기는 setup_instruments 및 setup_objects 모두에서 ENABLED가 YES인 경우에만 이벤트를 생성합니다.

- 두 테이블의 TIMED 값이 결합되어 두 값이 모두 YES 인 경우에만 타이밍 정보가 수집됩니다.

또한 setup_instruments 및 setup_objects 테이블의 TIMED 컬럼을 결합하여 이벤트 타이밍 정보를 수집할지 여부를 결정하는 데 적용됩니다.

 

setup_instruments의 개체 관련 계측기가 ENABLED 값이 NO인 경우 개체에 대한 이벤트가 모니터링되지 않습니다.

ENABLED 값이 YES이면 관련 setup_objects 행의 ENABLED 값에 따라 이벤트 모니터링이 발생합니다.

 

저장된 프로그램 개체의 경우 성능 스키마는 setup_objects 행에서 직접 ENABLED 및 TIMED 컬럼을 가져옵니다. setup_instruments와 값을 결합하지 않습니다.

 

이 테이블의 최대 크기는 기본적으로 100 행입니다. 테이블 크기를 변경하려면 서버 시작시 performance_schema_setup_objects_size 시스템 변수를 수정합니다.

 

설정방법)

setup_objects 테이블은 패턴에 따른 설정 방법을 사용하고 있습니다.

위의 테이블에서 맨 앞의 OBJECT_TYPE은 모니터링해야 할 오브젝트 종류를 나타냅니다. 그리고 OBJECT_SCHEMA는 모니터링 대상 스키마, OBJECT_NAME은 모니터링 해야 할 오브젝트입니다.

%의 의미는 '모두'를 의미합니다.

 

성능 스키마가 setup_objects에서 일치를 확인할때 더 구체적인 일치를 먼저 찾으려고합니다. 주어진 OBJECT_TYPE과 일치하는 행의 경우 성능 스키마는 다음 순서로 행을 확인합니다.

- OBJECT_SCHEMA='literal' 및 OBJECT_NAME='literal'이 있는 행.

- OBJECT_SCHEMA='literal' 및 OBJECT_NAME='%'가 있는 행.

- OBJECT_SCHEMA='%' 및 OBJECT_NAME='%'가 있는 행.

예를 들어, db1.t1 테이블에서 성능 스키마는 테이블 행에서 'db1'및 't1'과 일치하는 항목을 찾은 다음 'db1'및 '%'를 찾은 다음 '%'및 '%'를 찾습니다.

일치하는 setup_objects 행이 서로 다른 ENABLED 및 TIMED 값을 가질 수 있으므로 일치가 발생하는 순서가 중요합니다.

 

설정예제)

1. db1스키마의 t1테이블에 대해 모니터링을 원할 경우

insert into setup_objects(OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME, ENABLED,TIMED) values(TABLE, db1, t1, YES, YES);

 

2. db1 스키마의 t2 테이블에 대해 모니터링을 제외할 경우

insert into setup_objects(OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME, ENABLED,TIMED) values(TABLE, db1, t2, NO, NO);

 

3. db2 스키마의 모든 테이블에 대해 모니터링을 원할 경우

insert into setup_objects(OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME, ENABLED,TIMED) values(TABLE, db2, %, YES, YES);

 

4. db3 스키마의 모든 테이블에 대해 모니터링을 제외할 경우

insert into setup_objects(OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME, ENABLED,TIMED) values(TABLE, db3, %, NO, NO);

 

5. 모든 스키마의 모든 테이블에 대해 모니터링을 원할 경우

insert into setup_objects(OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME, ENABLED,TIMED) values(TABLE, %, %, YES, YES);

 

위의 예제를 기반으로 다음과 같이 setup_objects가 설정되어 있다고 가정합니다.

+-------------+---------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+-------------+---------------+-------------+---------+-------+
| TABLE       | db1           | t1          | YES     | YES   |
| TABLE       | db1           | t2          | NO      | NO    |
| TABLE       | db2           | %           | YES     | YES   |
| TABLE       | db3           | %           | NO      | NO    |
| TABLE       | %             | %           | YES     | YES   |
+-------------+---------------+-------------+---------+-------+

db1.t1 이벤트는 모니터링 됩니다.

db1.t2 이벤트는 모니터링 되지 않습니다. db1에 속한 t2외의 다른 테이블들은 모니터링 됩니다.

db2.t3 이벤트는 모니터링 됩니다.

db3.t4 이벤트는 모니터링 되지 않습니다. 또한 db3 스키마의 모든 테이블들은 모니터링되지 않습니다.

db4.t5 이벤트는 모니터링 됩니다. 마지막 OBJECT_SCHEMA, OBJECT_NAME이 %, %인 관계로 필터링된 db1,db2,db3외의 모든 스키마는 모니터링 대상입니다.

 

만약 모니터링 대상을 위의 예제처럼 선택해서 관리한다면 맨아래 OBJECT_SCHEMA='%' 및 OBJECT_NAME='%' 설정은 하지 않는것이 좋습니다.

위에서 필터링이 되어도 다른 스키마가 필터링이 안되기 때문에 모든 스키마에 대해 전략적으로 필터링을 걸어야 합니다.

 

 

 

 

▶︎ threads 테이블 및 setup_actors 테이블

위의 2개 테이블은 서로 관련이 있습니다. 설정방법에 대해 알아보겠습니다.

 

• threads 테이블

threads 테이블에는 각 서버 스레드에 대한 여러행이 있습니다. 각 행에는 스레드에 대한 정보가 포함되어 있으며 모니터링이 활성화되었는지 여부를 나타냅니다.

성능 스키마가 스레드를 모니터링하려면 다음 사항이 참이어야합니다.

- setup_consumers 테이블의 thread_instrumentation는 YES여야 합니다.

- threads테이블의 INSTRUMENTED 컬럼은 YES 여야합니다.

- 모니터링은 setup_instruments 테이블에서 활성화 된 기기에서 생성 된 스레드 이벤트에 대해서만 발생합니다.

 

threads 테이블은 히스토리 이벤트 로깅을 수행할지 여부를 각 서버 스레드에 대해 표시합니다.

여기에는 wait, stage, statement 및 transaction 이벤트가 포함되며 다음 테이블에 대한 로깅과 관련이 있습니다.

events_waits_history
events_waits_history_long
events_stages_history
events_stages_history_long
events_statements_history
events_statements_history_long
events_transactions_history
events_transactions_history_long

위의 이벤트들에 대해 활성화가 되려면 setup_consumers테이블에서 해당 이벤트에 대한 기록 관련 설정을 활성화 해주어야 합니다.

예를 들어 events_waits_history 및 events_waits_history_long 테이블에 대기 이벤트 로깅을 수행하려면

해당 events_waits_history 및 events_waits_history_long 소비자가 YES여야합니다. 

setup_consumers의 consumer 이름은 이벤트 이름 및 이벤트 테이블 이름과 같으므로 쉽게 구별이 가능합니다.

또한 로깅은 setup_instruments 테이블에서 활성화된 계측기에서 생성된 스레드 이벤트에 대해서만 발생합니다.

 

• setup_actors 테이블

새로운 포 그라운드 스레드에 대한 모니터링을 초기화하는 방법입니다.

이 테이블의 최대 크기는 기본적으로 100 행입니다. 테이블 크기를 변경하려면 서버 시작시 performance_schema_setup_actors_size 시스템 변수를 수정합니다.

 

포 그라운드 스레드(클라이언트 연결)의 경우 threads테이블 행에있는 INSTRUMENTED 및 HISTORY컬럼의 초기값은 연결된 사용자 계정이

setup_actors 테이블의 행과 일치하는지 여부에 따라 결정됩니다. 값은 일치하는 setup_actors 테이블 행의 ENABLED 및 HISTORY 컬럼에서 가져옵니다.

 

백그라운드 스레드의 경우 연결된 사용자가 없습니다. INSTRUMENTED 및 HISTORY는 기본적으로 YES이며 setup_actors는 참조되지 않습니다.

초기 setup_actors 내용은 다음과 같습니다.

mysql> SELECT * FROM performance_schema.setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| %    | %    | %    | YES     | YES     |
+------+------+------+---------+---------+

 

setup_actors는 setup_objects와 마찬가지로 패턴에 따른 설정 방법을 사용하고 있습니다.

HOST 및 USER 컬럼에는 리터럴 호스트 또는 사용자 이름 또는 모든 이름과 일치하는 '%'가 포함되어야합니다.

ENABLED 및 HISTORY 컬럼은 앞에서 설명한 다른 조건에 따라 일치하는 스레드에 대한 계측 및 기록 이벤트 로깅을 활성화할지 여부를 나타냅니다.

외부 접속으로 포그라운드 스레드가 생성될 때 setup_actors의 필터링 조건을 먼저 확인하게 됩니다. USER 및 HOST 컬럼을 비교하여 보다 구체적인 일치 항목을 찾으려고

합니다 (ROLE은 사용되지 않음).

- USER = 'literal'및 HOST = 'literal'인 행.

- USER = 'literal'및 HOST = '%'인 행.

- USER = '%'및 HOST = 'literal'인 행.

- USER = '%'및 HOST = '%'인 행.

 

일치하는 다른 setup_actors 행은 다른 USER 및 HOST 값을 가질 수 있으므로 일치가 발생하는 순서가 중요합니다.

이를 통해 ENABLED 및 HISTORY 컬럼 값을 기반으로 호스트, 사용자 또는 계정 (사용자 및 호스트 조합)별로 계측 및 기록 이벤트 로깅을 선택적으로 적용할 수 있습니다.

- 가장 일치하는 항목이 ENABLED=YES 행인 경우 threads 테이블의 INSTRUMENTED 컬럼값은 YES가됩니다.

  가장 일치하는 항목이 HISTORY=YES 행인 경우 threads의 HISTORY 컬럼값은 YES가됩니다.

- 가장 일치하는 항목이 ENABLED=NO 행이면 threads 테이블의 INSTRUMENTED 값은 NO가 됩니다.

  가장 일치하는 항목이 HISTORY=NO 행이면 threads 테이블의 HISTORY 값은 NO가 됩니다.

- 일치하는 항목이 없으면 스레드의 INSTRUMENTED 및 HISTORY 값이 NO가됩니다.

 

setup_actors행의 ENABLED 및 HISTORY 컬럼은 서로 독립적으로 YES 또는 NO로 설정할 수 있습니다. 즉, 기록 이벤트 수집 여부와는 별도로 계측을 활성화 할 수 있습니다.

기본적으로 setup_actors 테이블에는 HOST 및 USER 모두에 대해 '%'가 있는 행이 처음에 포함되어 있으므로 모든 새 포 그라운드 스레드에 대해 모니터링 및 기록 이벤트 수집이 활성화 됩니다.

일부 포그라운드 스레드에 대해서만 모니터링을 사용하도록 설정하는 것과 같이 보다 제한된 일치를 수행하려면 이 행이 모든 연결과 일치하므로 이 행을 변경하고

더 구체적인 HOST / USER 조합에 대한 행을 추가해야 합니다.

 

설정 예제)

UPDATE performance_schema.setup_actors
SET ENABLED = 'NO', HISTORY = 'NO'
WHERE HOST = '%' AND USER = '%';
INSERT INTO performance_schema.setup_actors
(HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('localhost','joe','%','YES','YES');
INSERT INTO performance_schema.setup_actors
(HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('hosta.example.com','joe','%','YES','NO');
INSERT INTO performance_schema.setup_actors
(HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('%','sam','%','NO','YES');

+----------------------+------+------+---------+---------+
| HOST                 | USER | ROLE | ENABLED | HISTORY |
+----------------------+------+------+---------+---------+
| %                    | %    | %    | NO      | NO      |
| localhost            | joe  | %    | YES     | YES     |
| hosta.example.com    | joe  | %    | YES     | NO      |
| %                    | sam  | %    | NO      | YES     |
+----------------------+------+------+---------+---------+

 

UPDATE 문은 계측 및 기록 이벤트 수집을 비활성화하도록 기본 일치를 변경합니다. INSERT문으로 보다 구체적인 일치 항목에 대한 행을 추가합니다.

이제 성능 스키마는 다음과 같이 새 연결스레드에 대한 INSTRUMENTED 및 HISTORY 값을 설정하는 방법을 결정합니다.

- joe가 로컬 호스트에서 연결되면 연결은 두번째 행과 일치합니다. threads 테이블의 INSTRUMENTED 컬럼 및 HISTORY 컬럼값은 YES가됩니다.

- joe가 hosta.example.com에서 연결되면 세번째 행과 일치합니다. threads 테이블의 INSTRUMENTED 컬럼값은 YES가되고 HISTORY 컬럼값은 NO가됩니다.

- joe가 다른 호스트에서 연결하면 일치하는 항목이 없습니다. 스레드의 INSTRUMENTED 및 HISTORY 값은 NO가됩니다.

- sam이 임의의 호스트에서 연결되는 경우 연결은 네번째 행과 일치합니다. 스레드의 INSTRUMENTED 값은 NO가되고 HISTORY 값은 YES가됩니다.

- 다른 연결의 경우 HOST 및 USER가 '%'로 설정된 행이 일치합니다. 이 행에는 이제 ENABLED 및 HISTORY가 NO로 설정되어 스레드의 INSTRUMENTED 및 HISTORY 값이 NO가됩니다.

setup_actors 테이블에 대한 수정은 기존 스레드가 아닌 수정 이후에 생성 된 포 그라운드 스레드에만 영향을줍니다.

기존 스레드에 영향을 미치려면 스레드 테이블 행의 INSTRUMENTED 및 HISTORY 컬럼을 수정합니다.

 

 

■ 계측기(setup_instruments)의 종류

계측기에는 400개가 넘는 계측기가 있습니다. 이 계측기들의 카테고리별 특징에 대해 알아보겠습니다.

계측기 이름을 보면 어떤 역활을 하는지 어느정도 이해할 수 있습니다. 인스트루먼트되는 것은 서버 코드입니다. 이 코드에 대한 변경이 자주 발생하며 이는 계측기 세트에도 영향을줍니다.

수백 개의 계측기가 있기 때문에 모든 계측기를 나열하는 것은 실용적이지 않습니다.

앞에서 설명한 것처럼 setup_instruments 테이블을 쿼리하여 찾을 수 있습니다. 이 정보는 MySQL 버전에 대해 항상 최신 상태이며 코어 서버의 일부가 아니고 자동화 된 도구에서 사용할 수있는 사용자가 설치했을 수있는 계측 플러그인에 대한 계측도 포함됩니다.

 

▶︎ idle 계측 요소.

계측된 유휴 이벤트입니다. 이 계측기에는 추가 요소가 없습니다.

유휴 계측기는 유휴 이벤트에 사용됩니다.

 

▶︎ memory 계측 요소.

계측된 메모리 이벤트입니다. 

대부분의 메모리 계측은 기본적으로 비활성화되어 있으며 시작시 활성화 또는 비활성화하거나 setup_instruments 테이블에서 관련 계측기의 ENABLED 컬럼을 업데이트하여 런타임에 동적으로 활성화 또는 비활성화 할 수 있습니다.

메모리 계측기에는 memory/code_area/instrument_name 형식의 이름이 있습니다. 여기서 code_area는 sql 또는 myisam과 같은 값이고 instrument_name은 계측기 세부 정보입니다.

 

접두사 memory/performance_schema/로 시작되는 계측기는 성능 스키마에서 내부 버퍼에 할당된 메모리 양을 표시합니다. memory/performance_schema/Instruments는 내장되어 있으며 항상 활성화되어 있으며 시작 또는 런타임시 비활성화 할 수 없습니다. 내장 메모리 기기는 memory_summary_global_by_event_name 테이블에만 표시됩니다.

자세한 내용은 맨 아래 "성능 스키마 메모리 할당 모델”을 참고하세요.

 

▶︎ stage 계측 요소

계측된 stage 이벤트입니다.

stage 계측기의 이름은 stage/code_area/stage_name 형식입니다. 여기서 code_area는 sql 또는 myisam과 같은 값이고 stage_name은 결과 정렬 또는 데이터 전송과 같은 명령문 처리 단계를 나타냅니다.

스테이지는 SHOW PROCESSLIST에 표시되거나 INFORMATION_SCHEMA.PROCESSLIST 테이블에 표시되는 스레드 상태에 해당합니다.

 

▶︎ statement 계측 요소

계측된 명령문 이벤트입니다

• statement/abstract/* : 명령문 작업을 위한 추상 도구입니다. 추상 도구는 정확한 statement 유형이 알려지기 전에 statement 분류의 초기 단계에서 사용된 다음 유형이 알려지면보다 구체적인 명령문 도구로 변경됩니다.

• statement/com : 계측된 명령 작업입니다. COM_xxx 작업에 해당하는 이름이 있습니다

(mysql_com.h 헤더파일 및 sql/sql_parse.cc 참조.). 예를 들어 statement/com/Connect 및 statement/com/Init DB 계측기는 COM_CONNECT 및 COM_INIT_DB 명령에 해당합니다.

• statement/scheduler/event : 이벤트 스케줄러가 실행하는 모든 이벤트를 추적하는 단일 도구입니다. 이 계측기는 예정된 이벤트가 실행되기 시작하면 작동합니다.

• statement/sp : 저장된 프로그램에 의해 실행되는 계측된 내부 명령어. 예를 들어 statement/sp/cfetch 및 statement/sp/freturn 도구는 커서 가져 오기 및 함수 반환 명령에 사용됩니다.

• statement/sql : 계측된 SQL문 작업입니다. 예를 들어 statement/sql/create_db 및 statement/sql/select 도구는 CREATE DATABASE 및 SELECT 문에 사용됩니다.

 

▶︎ wait 계측 요소

계측된 대기 이벤트입니다.

• wait/io : 계측된 I/O 작업입니다.

+ wait/io/file : 

인스트루먼트 된 파일 I/O 작업. 파일의 경우 대기는 파일 작업이 완료되기를 기다리는 시간입니다 (예 : fwrite () 호출). 캐싱으로 인해 디스크의 실제 파일 I/O가 이 호출 내에서 발생하지 않을 수 있습니다.

 

+ wait/io/socket

계측 된 소켓 작업입니다. 소켓 인스트루먼트에는 wait/io/socket/sql/socket_type 형식의 이름이 있습니다. 서버에는 지원하는 각 네트워크 프로토콜에 대한 수신 소켓이 있습니다. TCP/IP 또는 Unix소켓 파일 연결을 위한 청취 소켓과 관련된 계측기는 각각 socket_type 값이 server_tcpip_socket 또는 server_unix_socket입니다. 청취 소켓이 연결을 감지하면 서버는 별도의 스레드에서 관리하는 새 소켓으로 연결을 전송합니다. 새 연결 스레드의 계측기에는 client_connection의 socket_type 값이 있습니다.

 

3.wait/io/table

계측된 테이블 I/O 작업입니다. 여기에는 영구 기본 테이블 또는 임시 테이블에 대한 행 수준 액세스가 포함됩니다. 행에 영향을주는 작업은 페치, 삽입, 업데이트 및 삭제입니다.

뷰의 경우 대기는 뷰에서 참조하는 기본 테이블과 연결됩니다.

대부분의 대기와 달리 테이블 I/O 대기에는 다른 대기가 포함될 수 있습니다. 예를 들어 테이블 I/O에는 파일 I/O 또는 메모리 작업이 포함될 수 있습니다. 따라서 테이블 I/O 대기에 대한 events_waits_current에는 일반적으로 두 개의 행이 있습니다. 자세한 내용은 섹션 24.8,“성능 스키마 원자 및 분자 이벤트”를 참조하십시오.

일부 행 작업으로 인해 여러 테이블 I/O 대기가 발생할 수 있습니다. 예를 들어 삽입은 업데이트를 유발하는 트리거를 활성화 할 수 있습니다.

 

• wait/lock : 계측된 잠금 작업입니다.

+ wait/lock/table

계측 된 테이블 잠금 작업입니다.

 

+ wait/lock/metadata/sql/mdl

계측된 메타 데이터 잠금 작업입니다.

 

• wait/synch : 계측된 동기화 개체입니다. 동기화 개체의 경우 TIMER_WAIT 시간에는 개체에 대한 잠금을 획득하려고 시도하는 동안 차단된 시간이 포함됩니다.

+ wait/synch/cond

조건은 한 스레드가 기다리고 있던 일이 발생했음을 다른 스레드에 알리는데 사용됩니다. 단일 스레드가 조건을 기다리고있는 경우 깨어나 실행을 계속할 수 있습니다.

여러 스레드가 대기 중이면 모두 깨어나 대기중인 리소스를두고 경쟁할 수 있습니다.

 

+ wait/synch/mutex

다른 스레드가 리소스에 액세스하지 못하도록 차단하면서 리소스(예:실행 코드 섹션)에 대한 액세스를 허용하는 데 사용되는 상호 제외 개체입니다.

 

+ wait/synch/rwlock

액세스를 위해 특정 변수를 잠그고 다른 스레드에서 사용하지 못하도록하는 데 사용되는 읽기/쓰기 잠금 개체입니다. 공유 읽기 잠금은 여러 스레드에서 동시에 획득할 수 있습니다.

단독 쓰기 잠금은 한번에 하나의 스레드에서만 얻을 수 있습니다.

 

+ wait/synch/sxlock

공유 배타적 (SX) 잠금은 다른 스레드에서 일관되지 않은 읽기를 허용하면서 공통 리소스에 대한 쓰기 액세스를 제공하는 rwlock 잠금 개체 유형입니다.

sxlocks는 동시성을 최적화하고 읽기-쓰기 워크로드의 확장 성을 향상시킵니다.

 

▶︎ transaction

계측된 트랜잭션 이벤트입니다. 이 계측기에는 추가 요소가 없습니다.

 

■ 현재(current) 및 기록(history) 이벤트에 대한 성능 스키마 테이블

wait, stage, statement, 그리고 transaction events의 경우 성능 스키마는 현재 이벤트를 모니터링하고 저장할 수 있습니다. 또한 이벤트가 종료되면 성능 스키마는 이벤트를 기록 테이블에 저장할 수 있습니다. 각 이벤트 유형에 대해 성능 스키마는 현재 및 기록 이벤트를 저장하기 위해 세 개의 테이블을 사용합니다. 테이블에는 다음 형식의 이름이 있습니다. 여기서 xxx는 이벤트 유형 (대기, 단계, 명령문, 트랜잭션)을 나타냅니다.

+ events_xxx_current : "현재 이벤트"테이블은 각 스레드에 대해 현재 모니터링되는 이벤트를 저장합니다 (스레드 당 한 행). 현재 이벤트가 종료되면 테이블에서 제거됩니다.

+ events_xxx_history : "최근 히스토리"테이블은 스레드당 종료된 가장 최근 이벤트를 저장합니다 (스레드 당 최대 행 수).

+ events_xxx_history_long : "긴 히스토리"테이블은 전체적으로 종료 된 가장 최근 이벤트를 저장합니다 (모든 스레드에서 테이블 당 최대 행 수).

 

xxx_current 테이블은 파라미터 설정이 없으며 xxx_history, xxx_history_long 테이블은 기록할 수 있는 행수를 설정합니다.

일반적인 자동 크기 값은 _history 테이블의 경우 스레드 당 10 행이고 _history_long 테이블의 경우 총 10,000 행입니다.

 

_history 및 _history_long 테이블은 최근에 발생한 일을 보여줍니다. 히스토리 테이블이 가득 차면 새 이벤트가 추가 될 때 이전 이벤트가 삭제됩니다. 테이블의 용도가 다르기 때문에 행은 _history 및 _history_long 테이블에서 다른 방식으로 만료됩니다.

+ _history는 전역 서버로드와 관계없이 개별 스레드를 조사하기위한 것입니다.

+ _history_long은 각 스레드가 아닌 전역 적으로 서버를 조사하기위한 것입니다.

스레드가 종료되면 모든 행이 _history 테이블에서 삭제되지만 _history_long 테이블에서는 삭제되지 않습니다.

 

• 히스토리 테이블 예제

다음 예제는 두 가지 유형의 히스토리 테이블에서 이벤트가 추가 및 삭제되는 방식의 차이점을 보여줍니다. 원칙은 모든 이벤트 유형에 동일하게 적용됩니다. 이 예는 다음 가정을 기반으로합니다.

+ Performance Schema는 _history 테이블에서 스레드당 10개의 행을 유지하고 _history_long 테이블에서 총 10,000 개의 행을 유지하도록 구성됩니다.

+ 스레드 A는 초당 1 개의 이벤트를 생성합니다. 스레드 B는 초당 100 개의 이벤트를 생성합니다.

+ 다른 스레드가 실행되고 있지 않습니다.

 

5초 실행 후 :

+ A와 B는 각각 5 개와 500 개의 이벤트를 생성했습니다.

+ _history는 A에 대해 5개 행과 B에 대해 10개 행을 포함합니다. 스레드당 스토리지가 10개 행으로 제한되기 때문에 A에 대해 삭제된 행이없는 반면 B에 대해 삭제된 행은 490개입니다.

+ _history_long은 A에 대해 5개 행과 B에 대해 500개 행을 포함합니다. 테이블의 최대 크기는 10,000행이므로 두 스레드에 대해 삭제된 행이 없습니다.

 

5분 (300 초) 실행 후 :

+ A와 B는 각각 300 개와 30,000 개의 이벤트를 생성했습니다.

+ _history는 A에 대해 10 개 행을 포함하고 B에 대해 10 개 행을 포함합니다. 스레드 당 스토리지가 10 개 행으로 제한되므로 A에 대해 290 개 행이 삭제 된 반면 B에 대해 29,990 개 행이 삭제되었습니다.

A에 대한 행에는 최대 10 초 이전의 데이터가 포함됩니다. B의 행에는 최대 .1 초 이전의 데이터 만 포함됩니다.

+ _history_long에는 10,000 개의 행이 있습니다. A와 B가 함께 초당 101 개의 이벤트를 생성하기 때문에 테이블에는 A가 아닌 B에서 행이 약 100 대 1로 혼합되어있는 최대 약 10,000 / 101 = 99 초 이전의 데이터가 포함됩니다.

 

 

 

■ Performance Schema Statement Digests(성능 스키마 명령문 요약)

MySQL 서버는 명령문 요약 정보를 유지할 수 있습니다. Digests 프로세스는 각 SQL문을 정규화된 형식(문 다이제스트)으로 변환하고 정규화된 결과에서 MD5 해시값(다이제스트 해시 값)을 계산합니다.

정규화는 유사한 명령문을 그룹화하고 요약하여 서버가 실행하는 명령문 유형과 발생 빈도에 대한 정보를 노출합니다.

 

▶︎ Statement Digest 일반 개념

구문 분석기가 SQL문을 수신하면 해당 다이제스트가 필요한 경우 Statement 다이제스트를 계산합니다. Performance Schema 다이제스트 계측이 활성화되면 바로 수행됩니다.

 

max_digest_length 시스템 변수값은 정규화된 명령문 다이제스트 계산을 위해 세션당 사용 가능한 최대 바이트 수를 결정합니다. 다이제스트 계산 중에 해당 공간이 사용되면 잘림이 발생합니다.

구문 분석된 문에서 더이상 토큰이 수집되지 않거나 다이제스트 값으로 계산되지 않습니다.

많은 바이트의 명령문 분석된 토큰 이후에만 다른 문은 동일한 정규화된 명령문 다이제스트를 생성하며 비교하거나 다이제스트 통계에 대해 집계된 경우 동일한 것으로 간주됩니다.

 

정규화된 명령문이 계산된 후 MD5 해시 값이 계산됩니다. 추가적으로 다음과 같은것이 있습니다:

- 쿼리 재 작성 플러그인이 활성화 된 경우 해당 플러그인이 호출되고 명령문 요약 및 요약 값을 사용할 수 있습니다.

- 성능 스키마에 다이제스트 계측이 활성화된 경우 정규화된 명령문 다이제스트의 복사본을 만들어 최대 performance_schema_max_digest_length 바이트를 할당합니다. 결과적으로 performance_schema_max_digest_length가 max_digest_length보다 작으면 원본을 기준으로 복사본이 잘립니다. 정규화된 명령문 다이제스트의 복사본은 원래 정규화된 명령문에서 계산된 MD5 해시 값과 함께 적절한 성능 스키마 테이블에 저장됩니다.

(성능 스키마가 원본을 기준으로 정규화된 명령문 다이제스트의 복사본을 자를경우 MD5 해시값을 다시 계산하지 않습니다.)

 

명령문 정규화는 명령문 텍스트를 구조에 필수적이지 않은 정보를 제거하면서 일반 명령문 구조를 유지하는 보다 표준화된 다이제스트 문자열 표현으로 변환합니다.

- 데이터베이스 및 테이블 이름과 같은 개체 식별자는 유지됩니다.

- 리터럴 값은 매개 변수 마커로 변환됩니다. 정규화된 명령문은 이름, 암호, 날짜 등과 같은 정보를 유지하지 않습니다.

- 주석이 제거되고 공백이 조정됩니다.

 

▶︎ Statement Digest가 저장되는 예제

예제 1)

SELECT * FROM orders WHERE customer_id=10 AND quantity>20
SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100

 

이러한 명령문을 정규화하기 위해 파서는 데이터 값을 ?(물음표)공백을 조정합니다. 두 명령문 모두 동일한 정규화된 형식을 생성하므로 동일한 것으로 간주됩니다.

SELECT * FROM orders WHERE customer_id = ? AND quantity > ?

정규화된 명령문은 더 작은 정보를 포함하지만 여전히 원래 명령문을 나타냅니다. 다른 데이터값을 가진 다른 유사한 명령문은 동일한 정규화된 형식을 갖습니다.

 

예제 2)

SELECT * FROM 고객 WHERE customer_id = 1000
SELECT * FROM 주문 WHERE customer_id = 1000

이 경우 개체 식별자가 다르기 때문에 정규화된 명령문이 다릅니다.

 

SELECT * FROM 고객 WHERE customer_id =?

SELECT * FROM 주문 WHERE customer_id =?

정규화가 다이제스트 버퍼에서 사용 가능한 공간 (max_digest_length에 의해 결정됨)을 초과하는 문을 생성하는 경우 잘림이 발생하고 텍스트가 "..."로 끝납니다.

"..." 다음에 나오는 부분에서만 다른 긴 정규화 된 문은 동일한 것으로 간주됩니다.

 

다음과 같은 명령문이 있습니다.

SELECT * from mytable WHERE cola = 10 AND colb = 20
SELECT * from mytable WHERE cola = 10 AND colc = 20

컷오프가 AND 바로 뒤에 발생하면 두 명령문 모두 다음과 같은 정규화된 형식을 갖습니다.

SELECT * FROM mytable WHERE cola =? and ...

이 경우 두 번째 컬럼 이름의 차이가 손실되고 두 문이 동일한 것으로 간주됩니다.

 

 

▶︎ Statement Digests in the Performance Schema

성능 스키마에서 명령문 요약에는 다음 요소가 포함됩니다.

+ setup_consumers 테이블의 statements_digest 소비자는 성능 스키마가 다이제스트 정보를 유지하는지 여부를 제어합니다.

+ 문 이벤트 테이블 (events_statements_current, events_statements_history 및 events_statements_history_long)에는 정규화된 명령문 다이제스트와 해당 다이제스트 MD5 해시 값을 저장하기 위한 컬럼이 있습니다.

- DIGEST_TEXT는 정규화된 명령문 요약의 텍스트입니다. 이것은 최대 max_digest_length 바이트로 계산된 원래의 정규화된 명령문의 사본이며 필요에 따라 performance_schema_max_digest_length 바이트까지 더 잘립니다.

- DIGEST는 원래 정규화된 명령문에서 계산된 다이제스트 MD5 해시 값입니다.

 

+ events_statements_summary_by_digest 요약 테이블은 집계 된 명령문 요약 정보를 제공합니다. 이 테이블은 SCHEMA_NAME 및 DIGEST 조합에 따른 문에 대한 정보를 집계합니다.

성능 스키마는 계산 속도가 빠르고 충돌을 최소화하는 유리한 통계분포를 가지고 있기 때문에 집계에 MD5 해시 값을 사용합니다.

 

명령문 이벤트 테이블에는 원래 SQL 문을 포함하는 SQL_TEXT 컬럼도 있습니다. 명령문 표시에 사용할 수있는 최대 공간은 기본적으로 1024 바이트입니다.

이 값을 변경하려면 서버 시작시 performance_schema_max_sql_text_length 시스템 변수를 설정합니다.

 

performance_schema_max_digest_length 시스템 변수는 성능 스키마의 다이제스트 값 저장에 대해 명령문당 사용가능한 최대 바이트 수를 결정합니다.

그러나 명령문 요약의 표시 길이는 키워드 및 리터럴 값과 같은 명령문 요소의 내부 인코딩으로 인해 사용 가능한 버퍼 크기보다 길 수 있습니다.

결과적으로 명령문 이벤트 테이블의 DIGEST_TEXT 컬럼에서 선택한 값이 performance_schema_max_digest_length 값을 초과하는 것처럼 보일 수 있습니다.

 

events_statements_summary_by_digest 요약 테이블은 서버에서 실행한 명령문의 프로필을 제공합니다. 애플리케이션이 실행중인 명령문의 종류와 빈도를 보여줍니다.

응용 프로그램 개발자는이 정보를 표의 다른 정보와 함께 사용하여 응용 프로그램의 성능 특성을 평가할 수 있습니다.

예를 들어 대기시간, 잠금시간 또는 인덱스 사용을 표시하는 테이블 컬럼은 비효율적인 쿼리 유형을 강조하여 표시할 수 있습니다. 이를 통해 개발자는 애플리케이션에서 주의가 필요한 부분을 파악할 수 있습니다.

 

events_statements_summary_by_digest 요약 테이블의 크기는 고정되어 있습니다. 기본적으로 성능 스키마는 시작시 사용할 크기를 추정합니다.

테이블 크기를 명시 적으로 지정하려면 서버 시작시 performance_schema_digests_size 시스템 변수를 설정합니다.

테이블이 가득 차면 성능 스키마는 SCHEMA_NAME 및 DIGEST가 NULL로 설정된 특수 행의 테이블에있는 기존 값과 일치하지 않는 SCHEMA_NAME 및 DIGEST 값이있는 문을 그룹화합니다.

이렇게하면 모든 진술이 계산됩니다. 그러나 특수 행이 실행 된 명령문의 상당 부분을 차지하는 경우 performance_schema_digests_size를 늘려 요약 테이블 크기를 늘리는 것이 바람직 할 수 있습니다.

 

▶︎ Statement Digest Memory Use

끝에만 다른 매우 긴 명령문을 생성하는 응용 프로그램의 경우 max_digest_length를 늘리면 동일한 다이제스트로 집계되는 문을 구별하는 다이제스트를 계산할 수 있습니다.

반대로, max_digest_length를 줄이면 서버가 저장소를 다이제스트하는데 더 적은 메모리를 할당하지만 더 긴 명령문이 동일한 다이제스트에 집계될 가능성이 높아집니다.

관리자는 값이 클수록 특히 많은 수의 동시 세션이 포함된 워크로드의 경우 메모리 요구 사항이 증가한다는 점을 명심해야합니다(서버는 세션당 max_digest_length 바이트 할당).

 

이전에 설명한대로 구문 분석기에 의해 계산된 정규화된 명령문 다이제스트는 최대 max_digest_length 바이트로 제한되는 반면 성능 스키마에 저장된 정규화된 명령문 다이제스트는

performance_schema_max_digest_length 바이트를 사용합니다. max_digest_length 및 performance_schema_max_digest_length의 상대값과 관련하여 아래의 메모리 사용 고려사항이 적용됩니다.

 

+ max_digest_length가 performance_schema_max_digest_length보다 작은 경우 :

- Perfomance Schema 이외의 서버 구성 요소는 최대 max_digest_length 바이트를 차지하는 정규화된 명령문 다이제스트를 사용합니다.

- Perfomance Schema는 저장하는 정규화된 명령문 다이제스트를 더 이상 자르지 않지만 다이제스트당 max_digest_length 바이트보다 많은 메모리를 할당하므로 필요하지 않습니다.

 

+ max_digest_length가 performance_schema_max_digest_length와 같은 경우 :

- Perfomance Schema 이외의 서버 구성 요소는 최대 max_digest_length 바이트를 차지하는 정규화된 명령문 다이제스트를 사용합니다.

- Perfomance Schema는 저장하는 정규화된 명령문 다이제스트를 더 이상 자르지 않고 다이제스트당 max_digest_length 바이트와 동일한 양의 메모리를 할당합니다.

 

+ max_digest_length가 performance_schema_max_digest_length보다 큰 경우 :

- Perfomance Schema 이외의 서버 구성 요소는 최대 max_digest_length 바이트를 차지하는 정규화된 문 다이제스트를 사용합니다.

- Perfomance Schema는 저장하는 정규화 된 문 다이제스트를 추가로 자르고 다이제스트 당 max_digest_length 바이트보다 적은 메모리를 할당합니다.

 

Performance Schema 문 이벤트 테이블은 많은 다이제스트를 저장할 수 있으므로 performance_schema_max_digest_length를 max_digest_length보다 작게 설정하면 관리자가 다음 요소의 균형을 맞출 수 있습니다.

+ Perfomance Schema 외부의 서버 구성 요소에 사용할 수있는 긴 정규화 된 문 다이제스트가 필요함

+ 각각 다이제스트 계산 메모리를 할당하는 많은 동시 세션

+ 많은 명령문 다이제스트를 저장할때 Perfomance Schema 명령문 이벤트 테이블에 의한 메모리 소비를 제한해야 하는 필요성

 

performance_schema_max_digest_length 설정은 세션당이 아니라 명령문당이며 세션은 events_statements_history 테이블에 여러 문을 저장할 수 있습니다.

이 테이블의 일반적인 명령문 수는 세션 당 10개이므로 각 세션은 이 테이블에 대해서만 performance_schema_max_digest_length 값으로 표시된 메모리의 10배를 사용합니다.

 

또한, 특히 events_statements_history_long 테이블에 전역적으로 수집된 많은 명령문(및 다이제스트)이 있습니다. 여기서도 N 개의 저장된 문은 performance_schema_max_digest_length 값에 표시된 메모리의 N 배를 사용합니다.

 

SQL문 저장 및 다이제스트 계산에 사용되는 메모리 양을 평가하려면 SHOW ENGINE PERFORMANCE_SCHEMA STATUS 문을 사용하거나 다음 계측기를 모니터링합니다.

mysql> SELECT NAME
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE '%.sqltext';
+------------------------------------------------------------------+
| NAME                                                             |
+------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.sqltext      |
| memory/performance_schema/events_statements_current.sqltext      |
| memory/performance_schema/events_statements_history_long.sqltext |
+------------------------------------------------------------------+

mysql> SELECT NAME
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'memory/performance_schema/%.tokens';
+----------------------------------------------------------------------+
| NAME                                                                 |
+----------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.tokens           |
| memory/performance_schema/events_statements_current.tokens           |
| memory/performance_schema/events_statements_summary_by_digest.tokens |
| memory/performance_schema/events_statements_history_long.tokens      |
+----------------------------------------------------------------------+

 

■ 성능 스키마 메모리 할당 모델

성능 스키마는 다음 메모리 할당 모델을 사용합니다.

- 서버 시작시 메모리 할당 가능

- 서버 운영 중 추가 메모리 할당 가능

- 서버 작동 중에는 메모리를 확보하지 마십시오 (재활용 할 수 있음).

- 종료시 사용된 모든 메모리 해제

 

그 결과 메모리 제약을 완화하여 성능 스키마를 더 적은 구성으로 사용할 수 있고 메모리 사용량을 줄여서 서버 부하에 따라 사용량이 확장됩니다. 사용되는 메모리는 예상되거나 명시 적으로 구성된로드가 아니라 실제로 표시되는로드에 따라 다릅니다.

 

여러 성능 스키마 크기 조정 매개 변수가 자동 확장되며 메모리 할당에 대한 명시적 제한을 설정하지 않는한 명시적으로 구성할 필요가 없습니다. 해당 파라미터는 다음과 같습니다.

performance_schema_accounts_size
performance_schema_hosts_size
performance_schema_max_cond_instances
performance_schema_max_file_instances
performance_schema_max_index_stat
performance_schema_max_metadata_locks
performance_schema_max_mutex_instances
performance_schema_max_prepared_statements_instances
performance_schema_max_program_instances
performance_schema_max_rwlock_instances
performance_schema_max_socket_instances
performance_schema_max_table_handles
performance_schema_max_table_instances
performance_schema_max_table_lock_stat
performance_schema_max_thread_instances
performance_schema_users_size

 

자동 확장 매개 변수의 경우 구성은 다음과 같이 작동합니다.

• 값을 -1 (기본값)로 설정하면 매개 변수가 자동 확장됩니다.

- 해당 내부 버퍼는 처음에 비어 있으며 메모리가 할당되지 않습니다.

- 성능 스키마가 데이터를 수집함에 따라 해당 버퍼에 메모리가 할당됩니다. 버퍼 크기는 제한이 없으며로드에 따라 증가 할 수 있습니다.

 

• 값이 0으로 설정된 경우 :

해당 내부 버퍼는 처음에 비어 있으며 메모리가 할당되지 않습니다.

 

• 값이 N> 0으로 설정된 경우 :

- 해당 내부 버퍼는 처음에 비어 있으며 메모리가 할당되지 않습니다.

- 성능 스키마가 데이터를 수집함에 따라 버퍼 크기가 N에 도달 할 때까지 해당 버퍼에 메모리가 할당됩니다.

- 버퍼 크기가 N에 도달하면 더 이상 메모리가 할당되지 않습니다. 이 버퍼에 대해 성능 스키마에서 수집 한 데이터가 손실되고 해당 "손실 된 인스턴스"카운터가 증가합니다.

 

성능 스키마가 사용하는 메모리 양을 확인하려면 해당 용도로 설계된 계측기를 확인하십시오. 성능 스키마는 메모리를 내부적으로 할당하고 각 버퍼를 전용 장비와 연결하여 메모리 사용량을 개별 버퍼로 추적 할 수 있습니다. 접두사 memory/performance_schema/ 로 시작하는 계측기는 이러한 내부 버퍼에 할당된 메모리 양을 알려줍니다. 버퍼는 서버에 대해 전역이므로 계측기는 memory_summary_global_by_event_name 테이블에만 표시되고 다른 memory_summary_by_xxx_by_event_name 테이블에는 표시되지 않습니다.

 

이 쿼리는 메모리 기기와 관련된 정보를 보여줍니다.

mysql> SELECT * FROM performance_schema.memory_summary_global_by_event_name
WHERE EVENT_NAME LIKE 'memory/performance_schema/%';

 

 

▣ 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 테이블