Loading...
MySQL 9.5 Reference Manual 9.5의 29.12.6 Performance Schema Statement Event Tables의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
29.12.6.1 The events_statements_current Table 29.12.6.2 The events_statements_history Table 29.12.6.3 The events_statements_history_long Table 29.12.6.4 The prepared_statements_instances Table
Performance Schema는 스테이트먼트 실행을 계측합니다. 스테이트먼트 이벤트는 이벤트 계층 구조의 높은 레벨에서 발생합니다. 이벤트 계층 구조 내에서 대기 이벤트는 스테이지 이벤트 안에 중첩되고, 스테이지 이벤트는 스테이트먼트 이벤트 안에 중첩되며, 스테이트먼트 이벤트는 트랜잭션 이벤트 안에 중첩됩니다.
다음 테이블들은 스테이트먼트 이벤트를 저장합니다:
events_statements_current: 각 스레드에 대한
현재 스테이트먼트 이벤트입니다.
events_statements_history: 스레드당
종료된 가장 최근의 스테이트먼트 이벤트입니다.
events_statements_history_long:
전역적으로(모든 스레드에 걸쳐) 종료된
가장 최근의 스테이트먼트 이벤트입니다.
prepared_statements_instances:
프리페어드 스테이트먼트 인스턴스와 통계입니다.
다음 절에서는 스테이트먼트 이벤트 테이블들을 설명합니다. 스테이트먼트 이벤트에 대한 정보를 집계하는 요약 테이블도 있습니다. 자세한 내용은 Section 29.12.20.3, “Statement Summary Tables”를 참조하십시오.
세 개의
events_statements_xxx
이벤트 테이블 간의 관계에 대한 자세한 정보는
Section 29.9, “Performance Schema Tables for Current and Historical Events”를 참조하십시오.
스테이트먼트 이벤트를 수집할지 여부를 제어하려면, 관련 인스트루먼트와 컨슈머의 상태를 설정하십시오:
setup_instruments 테이블은
이름이 statement로 시작하는 인스트루먼트를
포함합니다. 이러한 인스트루먼트를 사용하여
개별 스테이트먼트 이벤트 클래스의 수집을
활성화하거나 비활성화합니다.
setup_consumers 테이블은
current 및 historical 스테이트먼트 이벤트 테이블 이름에
해당하는 이름을 가진 컨슈머 값과
스테이트먼트 다이제스트 컨슈머를 포함합니다.
이러한 컨슈머를 사용하여 스테이트먼트 이벤트 및
스테이트먼트 다이제스팅의 수집을 필터링합니다.
스테이트먼트 인스트루먼트는 기본적으로 활성화되어 있으며,
events_statements_current,
events_statements_history, 그리고
statements_digest 스테이트먼트 컨슈머는
기본적으로 활성화되어 있습니다:
1mysql> SELECT NAME, ENABLED, TIMED 2 FROM performance_schema.setup_instruments 3 WHERE NAME LIKE 'statement/%'; 4+---------------------------------------------+---------+-------+ 5| NAME | ENABLED | TIMED | 6+---------------------------------------------+---------+-------+ 7| statement/sql/select | YES | YES | 8| statement/sql/create_table | YES | YES | 9| statement/sql/create_index | YES | YES | 10... 11| statement/sp/stmt | YES | YES | 12| statement/sp/set | YES | YES | 13| statement/sp/set_trigger_field | YES | YES | 14| statement/scheduler/event | YES | YES | 15| statement/com/Sleep | YES | YES | 16| statement/com/Quit | YES | YES | 17| statement/com/Init DB | YES | YES | 18... 19| statement/abstract/Query | YES | YES | 20| statement/abstract/new_packet | YES | YES | 21| statement/abstract/relay_log | YES | YES | 22+---------------------------------------------+---------+-------+
1mysql> SELECT * 2 FROM performance_schema.setup_consumers 3 WHERE NAME LIKE '%statements%'; 4+--------------------------------+---------+ 5| NAME | ENABLED | 6+--------------------------------+---------+ 7| events_statements_current | YES | 8| events_statements_history | YES | 9| events_statements_history_long | NO | 10| statements_digest | YES | 11+--------------------------------+---------+
서버 스타트업 시에 스테이트먼트 이벤트 수집을 제어하려면,
my.cnf 파일에 다음과 같은 라인을 사용하십시오:
1[mysqld] 2performance-schema-instrument='statement/%=ON' 3performance-schema-consumer-events-statements-current=ON 4performance-schema-consumer-events-statements-history=ON 5performance-schema-consumer-events-statements-history-long=ON 6performance-schema-consumer-statements-digest=ON
1[mysqld] 2performance-schema-instrument='statement/%=OFF' 3performance-schema-consumer-events-statements-current=OFF 4performance-schema-consumer-events-statements-history=OFF 5performance-schema-consumer-events-statements-history-long=OFF 6performance-schema-consumer-statements-digest=OFF
런타임에 스테이트먼트 이벤트 수집을 제어하려면,
setup_instruments 및
setup_consumers 테이블을 업데이트하십시오:
1UPDATE performance_schema.setup_instruments 2SET ENABLED = 'YES', TIMED = 'YES' 3WHERE NAME LIKE 'statement/%'; 4 5UPDATE performance_schema.setup_consumers 6SET ENABLED = 'YES' 7WHERE NAME LIKE '%statements%';
1UPDATE performance_schema.setup_instruments 2SET ENABLED = 'NO', TIMED = 'NO' 3WHERE NAME LIKE 'statement/%'; 4 5UPDATE performance_schema.setup_consumers 6SET ENABLED = 'NO' 7WHERE NAME LIKE '%statements%';
특정 스테이트먼트 이벤트만 수집하려면, 해당하는 스테이트먼트 인스트루먼트만 활성화하십시오. 특정 스테이트먼트 이벤트 테이블에 대해서만 스테이트먼트 이벤트를 수집하려면, 스테이트먼트 인스트루먼트는 활성화하되 원하는 테이블에 해당하는 스테이트먼트 컨슈머만 활성화하십시오.
이벤트 수집 구성에 대한 추가 정보는 Section 29.3, “Performance Schema Startup Configuration”과 Section 29.4, “Performance Schema Runtime Configuration”를 참조하십시오.
스테이트먼트 모니터링은 서버가 스레드에서 액티비티가 요청되었음을 인지하는 순간부터 모든 액티비티가 종료될 때까지 시작됩니다. 일반적으로 이는 서버가 클라이언트로부터 첫 번째 패킷을 받는 시점부터, 서버가 응답 전송을 완료할 때까지를 의미합니다. 스토어드 프로그램 내의 스테이트먼트는 다른 스테이트먼트와 마찬가지로 모니터링됩니다.
Performance Schema가 요청(서버 커맨드 또는 SQL 스테이트먼트)을 계측할 때, 보다 일반적(또는 “abstract”)인 것에서 보다 구체적인 것으로 진행되는 인스트루먼트 이름을 사용하여 최종 인스트루먼트 이름에 도달할 때까지 단계적으로 진행합니다.
최종 인스트루먼트 이름은 서버 커맨드 및 SQL 스테이트먼트에 해당합니다:
서버 커맨드는 mysql_com.h 헤더 파일에
정의되고 sql/sql_parse.cc에서 처리되는
COM_xxx codes에 해당합니다.
예로는 COM_PING 및
COM_QUIT가 있습니다. 커맨드용 인스트루먼트의 이름은
statement/com으로 시작하며,
예로는 statement/com/Ping 및
statement/com/Quit가 있습니다.
SQL 스테이트먼트는 DELETE FROM t1 또는 SELECT * FROM t2와 같이 텍스트로 표현됩니다.
SQL 스테이트먼트용 인스트루먼트의 이름은
statement/sql로 시작하며,
예로는 statement/sql/delete 및
statement/sql/select가 있습니다.
일부 최종 인스트루먼트 이름은 에러 처리에 특화되어 있습니다:
statement/com/Error는 서버가 대역 외로
수신한 메시지를 계정합니다.
이는 서버가 이해하지 못하는 커맨드를 클라이언트가
전송했는지를 탐지하는 데 사용할 수 있습니다.
이는 잘못 구성되었거나 서버보다 더 최신 버전의
MySQL을 사용하는 클라이언트 또는
서버를 공격하려는 클라이언트를 식별하는 등의 목적으로
유용할 수 있습니다.
statement/sql/error는 파싱에 실패하는
SQL 스테이트먼트를 계정합니다.
이는 클라이언트가 전송한 형식이 잘못된 쿼리를 탐지하는 데
사용할 수 있습니다. 파싱에 실패하는 쿼리는
파싱은 되지만 실행 중 에러로 인해 실패하는 쿼리와는
다릅니다. 예를 들어, SELECT * FROM은 형식이 잘못되었으며,
statement/sql/error 인스트루먼트가 사용됩니다.
반대로 SELECT *는 파싱은 되지만
No tables used 에러와 함께 실패합니다.
이 경우에는 statement/sql/select가 사용되며,
스테이트먼트 이벤트에는 에러의 성격을 나타내는
정보가 포함됩니다.
요청은 다음 출처 중 어느 곳에서든 얻을 수 있습니다:
클라이언트로부터 커맨드 또는 스테이트먼트 요청으로서, 패킷으로 요청을 전송하는 경우
레플리카에서 릴레이 로그로부터 읽은 스테이트먼트 문자열인 경우
이벤트 스케줄러로부터의 이벤트인 경우
요청에 대한 세부 정보는 처음에는 알려져 있지 않으며, Performance Schema는 요청의 출처에 따라 달라지는 순서로 abstract에서 구체적인 인스트루먼트 이름으로 진행합니다.
클라이언트로부터 수신된 요청의 경우:
서버가 소켓 레벨에서 새로운 패킷을 감지하면,
새로운 스테이트먼트가
statement/abstract/new_packet라는 abstract 인스트루먼트 이름으로
시작됩니다.
서버가 패킷 번호를 읽으면,
수신된 요청의 타입에 대해 더 많이 알게 되며,
Performance Schema는 인스트루먼트 이름을 더 정교하게 만듭니다.
예를 들어, 요청이 COM_PING 패킷이면,
인스트루먼트 이름은 statement/com/Ping이 되고
이것이 최종 이름입니다. 요청이
COM_QUERY 패킷인 경우,
SQL 스테이트먼트에 해당하지만 특정한 스테이트먼트 타입은
알 수 없습니다. 이 경우, 인스트루먼트는 한 abstract 이름에서
보다 구체적이지만 여전히 abstract인 이름인
statement/abstract/Query로 변경되며,
요청은 추가 분류가 필요합니다.
요청이 스테이트먼트인 경우, 스테이트먼트 텍스트가 읽혀
파서에 전달됩니다. 파싱 후 정확한 스테이트먼트 타입이
알려집니다. 예를 들어, 요청이
INSERT 스테이트먼트인 경우,
Performance Schema는 인스트루먼트 이름을
statement/abstract/Query에서
최종 이름인 statement/sql/insert로
정교화합니다.
레플리카에서 릴레이 로그의 스테이트먼트로서 읽힌 요청의 경우:
릴레이 로그의 스테이트먼트는 텍스트로 저장되며
그렇게 읽혀집니다. 네트워크 프로토콜이 없으므로
statement/abstract/new_packet 인스트루먼트는
사용되지 않습니다. 대신 첫 인스트루먼트는
statement/abstract/relay_log입니다.
스테이트먼트가 파싱되면 정확한 스테이트먼트 타입이
알려집니다. 예를 들어, 요청이
INSERT 스테이트먼트인 경우,
Performance Schema는 인스트루먼트 이름을
statement/abstract/Query에서
최종 이름인 statement/sql/insert로
정교화합니다.
앞선 설명은 스테이트먼트 기반 복제에만 적용됩니다. 로우 기반 복제의 경우, 레플리카에서 로우 변경을 처리하면서 수행되는 테이블 I/O는 계측될 수 있지만, 릴레이 로그의 로우 이벤트는 개별 스테이트먼트로 나타나지 않습니다.
이벤트 스케줄러로부터 수신된 요청의 경우:
이벤트 실행은
statement/scheduler/event라는 이름을 사용하여
계측됩니다. 이것이 최종 이름입니다.
이벤트 바디 내에서 실행되는 스테이트먼트는
statement/sql/* 이름을 사용하여,
그 전에 어떤 abstract 인스트루먼트도 사용하지 않고
계측됩니다. 이벤트는 스토어드 프로그램이며,
스토어드 프로그램은 실행 전에 메모리에서 프리컴파일됩니다.
따라서 런타임에는 파싱이 없으며,
각 스테이트먼트의 타입은 실행 시점에는 이미 알려져 있습니다.
이벤트 바디 내에서 실행되는 스테이트먼트는 자식 스테이트먼트입니다.
예를 들어, 이벤트가
INSERT 스테이트먼트를 실행하는 경우,
이벤트 자체의 실행은 부모이며
statement/scheduler/event를 사용하여 계측되고,
INSERT는 자식이며
statement/sql/insert를 사용하여 계측됩니다.
부모/자식 관계는 개별 계측된 오퍼레이션들
사이에서 유지됩니다.
이는 abstract에서 최종 인스트루먼트 이름으로의
정교화가 단일 계측된 오퍼레이션 내에서
발생하는 시퀀스와는 다릅니다.
스테이트먼트에 대해 통계를 수집하려면,
개별 스테이트먼트 타입에 사용되는 최종
statement/sql/* 인스트루먼트만 활성화하는 것으로는
충분하지 않습니다. Abstract
statement/abstract/* 인스트루먼트도
활성화되어야 합니다. 이는 모든 스테이트먼트 인스트루먼트가
기본적으로 활성화되어 있기 때문에
보통 문제가 되지 않습니다. 그러나 스테이트먼트 인스트루먼트를
선택적으로 활성화 또는 비활성화하는
애플리케이션은 abstract 인스트루먼트를 비활성화하면
개별 스테이트먼트 인스트루먼트에 대한
통계 수집도 비활성화된다는 점을
감안해야 합니다. 예를 들어,
INSERT 스테이트먼트에 대한
통계를 수집하려면,
statement/sql/insert가 활성화되어야 할 뿐만 아니라,
statement/abstract/new_packet 및
statement/abstract/Query도 활성화되어야 합니다.
마찬가지로, 복제된 스테이트먼트가 계측되려면
statement/abstract/relay_log가 활성화되어야 합니다.
statement/abstract/Query와 같은 abstract 인스트루먼트에 대해
집계되는 통계는 없습니다. 왜냐하면 어떤 스테이트먼트도
abstract 인스트루먼트를 최종 스테이트먼트 이름으로 하여
분류되지 않기 때문입니다.
29.12.5 Performance Schema Stage Event Tables
29.12.7 Performance Schema Transaction Tables
