• MySQL매뉴얼
    • MySQL 5.6 매뉴얼
    • MySQL 5.1 매뉴얼
    • MySQL 5.0 매뉴얼
    • MySQL HA 매뉴얼
  • 기술문서
    • Xtrabackup 구성
    • 메모리 사용량 모니터링
  • 라이선스
  • 온라인문의
  • 회사소개
  • → 목 록 (MySQL5.6 한글메뉴얼) [close]
  • 1. MySQL 5.6 새로운 기능
  • 2. MySQL 설치 및 업그레이드
  • 3. MySQL Tutorial
  • 4. MySQL 프로그램
  • 5. MySQL 서버관리
  • 6. 보안
  • 7. 백업 및 복구
  • 8. 최적화
  • 9. Language Structure(언어구조)
  • 10. Character Sets(Globalization)
  • 11. 데이터형(Data Types)
  • 12. 함수와 연산자
  • 13. SQL 문법
  • 14. InnoDB 스토리지 엔진
  • 15. 기타 스토리지 엔진
  • 16. 고가용성 및 확장성
  • 17. 리플리케이션
  • 18. MySQL Cluster
  • 19. 파티셔닝
  • 20. Stored Programs and Views
  • 21. INFORMATION_SCHEMA
  • 22. PERFORMANCE SCHEMA
  • 1. Performance Schema 빠른 시작
    2. Performance Schema 구성
    3. Performance Schema 쿼리
    4. Performance Schema Instrument Naming Conventions
    5. Performance Schema Status Monitoring
    6. Performance Schema Atom and Molecule Events
    7. Performance Schema Statement Digests
    8. Performance Schema의 일반적인 테이블 특성
    9. Performance Schema 테이블 설명
    1. 성능 스키마 테이블 인덱스
    2. 성능 스키마 설정 테이블
    3. Performance Schema Instance Tables
    4. Performance Schema Wait Event Tables
    5. Performance Schema Stage Event Tables
    6. Performance Schema Statement Event Tables
    1. events_statements_current
    2. events_statements_history
    3. events_statements_history_long
    7. Performance Schema 연결 테이블
    8. Performance Schema 연결 속성 테이블
    9. Performance Schema 요약 테이블
    10. Performance Schema 기타 테이블
    10. Performance Schema Option and Variable Reference
    11. Performance Schema Command Options
    12. Performance Schema System Variables
    13. Performance Schema Status Variables
    14. Performance Schema and Plugins
    15. 문제를 진단하기위한 Performance Schema 사용
  • 23. 컨넥터 및 API
  • 24. MySQL 확장
  • 25. MySQL Enterprise Edition
  • 26. MySQL Workbench
  • 27. 제약 및 제한
  • 28. MySQL 5.7 새로운 기능

22.9.6 Performance Schema Statement Event Tables

22.9.6.1 events_statements_current 테이블
22.9.6.2 events_statements_history 테이블
22.9.6.3 events_statements_history_long 테이블

MySQL 5.6.3 현재 성능 스키마는 문 실행을 instrument합니다. 스테이트 이벤트 이벤트는 이벤트 계층의 높은 수준에서 발생합니다. 대기 이벤트 무대 이벤트에 중첩하여 스테이지 이벤트는 문 이벤트에 중첩합니다.

이 테이블은 문 이벤트를 저장합니다.

  • events_statements_current : 현재의 명령문 이벤트

  • events_statements_history : 각 스레드의 최신 문 이벤트

  • events_statements_history_long : 전체 최신의 문 이벤트

다음 섹션에서는 그 테이블에 대해 설명합니다. 문 이벤트에 대한 정보를 요약하는 요약 테이블도 있습니다. 섹션 22.9.9.3 "문 요약 테이블" 을 참조하십시오.

문 이벤트 구성

문 이벤트의 수집을 활성화하려면 관련 instrument와 소비자를 활성화합니다.

setup_instruments 테이블에는 statement 로 시작하는 이름을 가진 instrument가 포함됩니다. 이 instrument는 기본적으로 활성화되어 있습니다.

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'statement/%';
+---------------------------------------------+---------+-------+
| NAME                                        | ENABLED | TIMED |
+---------------------------------------------+---------+-------+
| statement/sql/select                        | YES     | YES   |
| statement/sql/create_table                  | YES     | YES   |
| statement/sql/create_index                  | YES     | YES   |
...
| statement/sp/stmt                           | YES     | YES   |
| statement/sp/set                            | YES     | YES   |
| statement/sp/set_trigger_field              | YES     | YES   |
| statement/scheduler/event                   | YES     | YES   |
| statement/com/Sleep                         | YES     | YES   |
| statement/com/Quit                          | YES     | YES   |
| statement/com/Init DB                       | YES     | YES   |
...
| statement/abstract/Query                    | YES     | YES   |
| statement/abstract/new_packet               | YES     | YES   |
| statement/abstract/relay_log                | YES     | YES   |
+---------------------------------------------+---------+-------+

문 이벤트의 수집을 변경하려면 관련 instrument의 ENABLED 및 TIMING 컬럼을 변경합니다. 예 :

mysql> UPDATE setup_instruments SET ENABLED = 'NO'
    -> WHERE NAME LIKE 'statement/com/%';

setup_consumers 테이블에는 현재 및 최근의 문 이벤트 테이블 이름에 해당하는 이름을 가진 소비자 값과 문 다이제스트 소비자가 저장됩니다. 이러한 소비자는 문 이벤트의 수집 및 문 다이제스트를 필터링하는 데 사용할 수 있습니다. events_statements_current 과 statements_digest 만 기본적으로 활성화되어 있습니다.

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%statements%';
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| events_statements_current      | YES     |
| events_statements_history      | NO      |
| events_statements_history_long | NO      |
| statements_digest              | YES     |
+--------------------------------+---------+

모든 문 소비자를 활성화하려면 다음을 수행합니다.

mysql> UPDATE setup_consumers SET ENABLED = 'YES'
    -> WHERE NAME LIKE '%statements%';

setup_timers 테이블에는 문 이벤트의 타이밍 단위를 나타내는 statement 의 NAME 값이있는 행이 포함됩니다. 기본 단위는 NANOSECOND 입니다.

mysql> SELECT * FROM setup_timers WHERE NAME = 'statement';
+-----------+------------+
| NAME      | TIMER_NAME |
+-----------+------------+
| statement | NANOSECOND |
+-----------+------------+

타이밍의 단위를 변경하려면 TIMER_NAME 값을 변경합니다.

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
    -> WHERE NAME = 'statement';

이벤트 모음 구성에 대한 자세한 내용은 섹션 22.2 "성능 스키마 구성" 을 참조하십시오.

Statement 모니터링

문 모니터링 서버가 스레드에 활동이 요청되어 있는지 확인한 시점에서 모든 활동이 종료 된 시점에 시작됩니다. 일반적으로 이것은 서버가 클라이언트에서 첫 번째 패킷을받은 때부터 서버가 응답의 전송을 종료 할 때까지를 의미합니다. 모니터링은 최상위 문에 대해서만 이루어집니다. 저장 프로그램과 하위 쿼리 문을 따로 볼 수 없습니다.

성능 스키마가 요청 (서버 명령 또는 SQL 문)을 instrument 경우 최종 instrument 이름에 도달 할 때까지 더 일반적인 (또는 "추상")에서보다 구체적으로 단계별 앞으로 instrument 이름을 사용합니다.

최종 instrument 이름은 서버 명령과 SQL 문을 지원합니다.

  • 서버 명령은 mysql_com.h 헤더 파일에 정의되어 sql/sql_parse.cc 에서 처리되는 COM_ xxx codes 에 대응합니다. 예 COM_PING 과 COM_QUIT 입니다. 명령의 instrument는 statement/com/Ping 이나 statement/com/Quit 등의 statement/com 에서 시작하는 이름을 가지고 있습니다.

  • SQL 문은 DELETE FROM t1 또는 SELECT * FROM t2 등의 텍스트로 표시됩니다. SQL 문 instrument는 statement/sql/delete 나 statement/sql/select 등의 statement/sql 에서 시작하는 이름을 가지고 있습니다.

일부 최종 instrument 이름은 오류 처리에 고유합니다.

  • statement/com/Error 는 대역 외 서버에 의해 수신 된 메시지로 구성됩니다. 이것은 서버가 이해하지 클라이언트가 전송 된 명령을 감지하는 데 사용할 수 있습니다. 이것은 구성이 잘못되었거나 서버보다 새로운 MySQL 버전을 사용하는 클라이언트와 서버에 대한 공격을 시도하는 클라이언트의 식별 등의 목적으로 유용 할 수 있습니다.

  • statement/sql/error 는 분석에 실패한 SQL 문으로 구성됩니다. 이것은 클라이언트가 보낸 잘못된 형식의 쿼리를 감지하는 데 사용할 수 있습니다. 분석에 실패하는 쿼리는 분석하지만, 실행중인 오류로 인해 실패하는 쿼리와 다릅니다. 예를 들어, SELECT * FROM 잘못된 형식으로 statement/sql/error instrument가 사용됩니다. 대조적으로 SELECT * 는 해석되지만 「No tables used error」 오류와 함께 실패합니다. 이 경우 statement/sql/select 가 사용 된 문장 이벤트는 오류의 특성을 나타내는 정보가 포함됩니다.

요청이 어떤 소스에서 얻을 수 있습니다.

  • 요청 패킷으로 보내는 클라이언트에서 명령 또는 문 요청으로

  • 복제 슬레이브의 릴레이 로그에서 읽어 들인 문 문자열로 (MySQL 5.6.13 이후)

요청 내용은 처음에는 알 수없는 성능 스키마는 요청의 소스에 의존하는 순서로 추상에서 특정 instrument 이름으로 이동합니다.

클라이언트에서 수신 한 요청의 경우 :

  1. 서버가 소켓 수준에서 새로운 패킷을 감지하면 새로운 문이 statement/abstract/new_packet 추상 instrument 이름에서 시작됩니다.

  2. 서버는 패킷 번호를 읽을 때받은 요청 유형에 대해 자세히 알고 성능 스키마가 instrument 이름을 검색합니다. 예를 들어, 요청이 COM_PING 패킷의 경우 instrument 이름은 statement/com/Ping 되고, 그것이 마지막 이름입니다. 요청이 COM_QUERY 패킷의 경우 그것은 SQL 문에 대응하지만, 특정 문 유형이 아니라는 것을 알 수 있습니다. 이 경우 instrument는 추상 이름에서 다소 구체적이지만 아직 추상 이름이다 statement/abstract/Query 로 변경 한 후 요청은 세분화해야합니다.

  3. 요청이 문이면 문 텍스트를 읽어 파서에 제공됩니다. 분석 후 정확한 문의 종류가 인식됩니다. 요청이 예를 들어 INSERT 문의 경우, 성능 스키마는 instrument 이름을 statement/abstract/Query 에서 최종 이름이다 statement/sql/insert 에 좁 힙니다.

복제 슬레이브의 릴레이 로그에서 문으로 읽을 요청의 경우 :

  1. 릴레이 로그의 문은 텍스트로 저장됩니다 그렇게 읽습니다. 네트워크 프로토콜이 아니기 때문에 statement/abstract/new_packet instrument는 사용되지 않습니다. 대신 초기 instrument는 statement/abstract/relay_log 됩니다.

  2. 구문이되면 정확한 문의 종류가 인식됩니다. 요청이 예를 들어 INSERT 문의 경우, 성능 스키마는 instrument 이름을 statement/abstract/Query 에서 최종 이름이다 statement/sql/insert 에 좁 힙니다.

앞서의 설명은 문 기반 복제에만 적용됩니다. 행 기반 복제에서는 행의 변경을 처리하면서 슬레이브로 실행되는 테이블 I / O를 instrument 수 있지만 릴레이 로그의 행 이벤트는 별도의 문으로 표시되지 않습니다.

문에 수집 된 통계의 경우 각 문 유형에 사용되는 최종 statement/sql/* instrument를 사용하는 것만으로는 충분하지 않습니다. 추상 statement/abstract/* instrument도 활성화해야합니다. 모든 문 instrument가 기본적으로 활성화되기 때문에 이것은 보통 문제가되지 않을 것입니다. 그러나 문 instrument를 선택하고 활성화 또는 비활성화하는 응용 프로그램은 추상 instrument를 비활성화하면 개별 문 instrument의 통계 수집도 무효화 될 것을 고려해야합니다. 예를 들어, INSERT 문 통계를 수집하려면 statement/sql/insert 를 활성화해야하지만 statement/abstract/new_packet 과 statement/abstract/Query 도 활성화해야합니다. 마찬가지로, 복제 된 문을 instrument하려면 statement/abstract/relay_log 가 활성화되어 있어야합니다.

문이 마지막 문 이름으로 추상 instrument로 분류되지 않기 때문에 statement/abstract/Query 등의 추상 instrument에 대한 통계는 집계되지 않습니다.

앞서 설명 추상 instrument 이름은 MySQL 5.6.15 현재입니다. 5.6 이전에는 그 이름이 결정되기까지 얼마간의 이름 변경이있었습니다.

  • MySQL 5.6.14에서는 statement/abstract/new_packet 는 statement/com/ 하고 MySQL 5.6.13에서는 statement/com/new_packet 에서 그 이전에는 statement/com/ 이었습니다.

  • MySQL 5.6.15 이전에는, statement/abstract/Query 는 statement/com/Query 이었습니다.

  • MySQL 5.6.13에서 5.6.14에서는 statement/abstract/relay_log 는 statement/rpl/relay_log 에서 이전에는 존재하지 않았습니다.


서울시 강남구 영동대로 602 6층
TEL: 02-6061-0006  /  E: csr@mysqlkorea.com
주식회사 이노클러스터  등록번호 : 727-86-02261
Copyright © innocluster Co. ltd. all rights reserved