제22장 MySQL Performance Schema

22.1 성능 스키마 빠른 시작
22.2 성능 스키마 구성
22.3 성능 스키마 쿼리
22.4 성능 스키마 instrument 명명 규칙
22.5 성능 스키마 상태 모니터링
22.6 성능 스키마의 원자 적 및 분자 이벤트
22.7 성능 스키마 문 다이제스트
22.8 성능 스키마의 일반적인 테이블 특성
22.9 성능 스키마 테이블의 설명
22.10 성능 스키마 옵션 및 변수 참조
22.11 성능 스키마 명령 옵션
22.12 성능 스키마 시스템 변수
22.13 성능 스키마 상태 변수
22.14 성능 스키마와 플러그인
22.15 문제를 진단하기위한 성능 스키마 사용

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

성능 스키마는 런타임 서버의 내부 실행을 검사하는 방법을 제공합니다. 그것은 PERFORMANCE_SCHEMA 스토리지 엔진 및 performance_schema 데이터베이스를 사용하여 구현됩니다. 성능 스키마는 주로 성능 데이터에 초점을 맞추고 있습니다. 이것은 메타 데이터의 검사에 사용되는 INFORMATION_SCHEMA 과 다릅니다.
성능 스키마는 서버 이벤트를 모니터합니다. "이벤트"는 시간이 걸리고 타이밍 정보를 수집 할 수 있도록 instrument 된 서버가 실행하는 모든 것입니다. 일반적으로 이벤트는 함수 호출 운영 체제의 대기 분석 및 정렬과 같은 SQL 문 실행 단계 또는 문 전체와 문 그룹 등입니다. 현재 이벤트 컬렉션 서버 및 일부 스토리지 엔진 동기 호출 (상호 배타 락을 위해) 파일 및 테이블 I / O 테이블 잠금 등 정보에 대한 액세스를 제공합니다.
성능 스키마 이벤트는 서버의 바이너리 로그에 기록되는 이벤트 (이것은 데이터의 변경을 설명하는)과 이벤트 스케줄러 이벤트 (이것은 내장 프로그램의 일종)과는 구별됩니다.
성능 스키마 이벤트는 MySQL 서버의 특정 인스턴스에 고유합니다. MySQL 5.6.9 이후에서는 성능 스키마 테이블은 서버에 로컬로 간주되며, 그들에게 변화는 바이너리 로그에 복제되거나 기록되지도 않습니다. (Bug # 14741537)
현재 이벤트 외에도, 이벤트 기록 및 요약을 얻을 수 있습니다. 그러면 instrument 된 활동이 여러 번 실행되고 그들에게 얼마나 시간이 걸 렸는지를 확인할 수 있습니다. 이벤트 정보를 검색하여 특정 스레드의 활동 또는 상호 배타 락이나 파일 등의 특정 개체에 관련된 활동을 볼 수 있습니다.
PERFORMANCE_SCHEMA 스토리지 엔진은 서버 소스 코드에서 "계측 포인트"를 사용하여 이벤트 데이터를 수집합니다.
수집 된 이벤트는 performance_schema 데이터베이스의 테이블에 저장됩니다. 이 테이블은 다른 테이블과 마찬가지로 SELECT 문을 사용하여 쿼리 할 수 있습니다.
성능 스키마의 구성은 SQL 문에서 performance_schema 데이터베이스의 테이블을 업데이트하여 동적으로 변경할 수 있습니다. 구성 변경은 데이터 컬렉션에 즉시 영향을주지 않습니다.
performance_schema 데이터베이스의 테이블은 영구적 인 디스크 스토리지를 사용하지 않는 뷰와 임시 테이블입니다.
모니터링은 MySQL에서 지원되는 모든 플랫폼에서 사용할 수 있습니다.

몇 가지 제한이 적용될 수 있습니다. 타이머의 종류는 플랫폼마다 다를 수 있습니다. 스토리지 엔진에 적용되는 instrument는 모든 스토리지 엔진에 구현되어 있지 않을 수 있습니다. 각 타사 엔진의 계측은 엔진 관리자의 책임입니다. 섹션 D.8 "성능 스키마에 대한 제한" 을 참조하십시오.
데이터 수집 서버 소스 코드를 변경하고 계측을 추가함으로써 구현됩니다. 복제 및 이벤트 스케줄러 등의 다른 기능과 달리 성능 스키마와 관련된 개별 스레드는 없습니다.

성능 스키마는 서버 성능에 미치는 영향을 최소화하면서 서버 실행에 대한 유용한 정보에 대한 액세스를 제공하는 것을 목적으로하고 있습니다. 구현은 이러한 설계 목표에 따릅니다.

성능 스키마 활성화하여 서버의 동작은 변경되지 않습니다. 예를 들어, 그로 인해 스레드 스케줄링이 변경되지 않고 쿼리 실행 계획 ( EXPLAIN 에 의해 표시되는)가 변경되지 않습니다.
서버 시작시에 열린 이상의 메모리 할당되지 않습니다. 고정 크기 구조의 조기 할당을 사용하여 그 크기를 조정하거나 재 할당 할 필요가 없습니다, 이것은 충분한 실행시 성능의 달성에 중요합니다.
서버의 모니터링은 매우 적은 오버 헤드로 반복적이고 눈에 띄지 않고 이루어집니다. 성능 스키마의 활성화에 따라 서버를 사용할 수 없게되지 않습니다.
파서는 변경되지 않습니다. 새로운 키워드와 문은 없습니다.
성능 스키마가 내부에서 실패해도 서버 코드의 실행은 정상적으로 진행됩니다.
초기의 이벤트를 수집 할 때 처리를 실행하거나 나중에 이벤트 검색시 처리를 실행하거나 중 하나를 선택하면 수집이 빨라지 쪽이 우선됩니다. 이것은 검색이 필요할 때 전혀되지 않을 수도있는 반면, 수집은 진행중이기 때문입니다.
새로운 계측 포인트를 추가하는 것은 간단합니다.
계측은 버전 관리됩니다. 계측 구현이 변경된 경우 이전에 instrument 된 코드가 계속 실행됩니다. 이것은 최신의 성능 스키마의 변경과 동기화시켜두기 위해 각 플러그인을 업그레이드 할 필요가 없기 때문에 타사 플러그인 개발자에게 메리트가 있습니다.