29장 MySQL 성능 스키마
목차
29.4.1 성능 스키마 이벤트 타이밍
29.4.2 성능 스키마 이벤트 필터링
29.4.3 이벤트 사전 필터링
29.4.4 기구별 사전 필터링
29.4.5 객체별 사전 필터링
29.4.6 스레드별 사전 필터링
29.4.7 소비자별 사전 필터링
29.4.8 소비자 구성 예시
29.4.9 필터링 작업을 위한 도구 또는 소비자 이름 지정
29.4.10 무엇이 계측되는지 결정하기
29.5 성능 스키마 쿼리
29.6 성능 스키마 도구 이름 지정 규칙
29.7 성능 스키마 상태 모니터링
29.8 성능 스키마 원자 및 분자 이벤트
29.9 현재 및 과거 이벤트에 대한 성능 스키마 테이블
29.10 성능 스키마 문장 요약 및 샘플링
29.11 성능 스키마 일반 테이블 특성
29.12 성능 스키마 테이블 설명
29.12.1 성능 스키마 테이블 참조
29.12.2 성능 스키마 설정 테이블
29.12.3 성능 스키마 인스턴스 테이블
29.12.4 성능 스키마 대기 이벤트 테이블
29.12.5 성능 스키마 단계 이벤트 테이블
29.12.6 성능 스키마 문장 이벤트 테이블
29.12.7 성능 스키마 트랜잭션 테이블
29.12.8 성능 스키마 연결 테이블
29.12.9 성능 스키마 연결 속성 테이블
29.12.10 성능 스키마 사용자 정의 변수 테이블
29.12.11 성능 스키마 복제 테이블
29.12.12 성능 스키마 NDB 클러스터 테이블
29.12.13 성능 스키마 잠금 테이블
29.12.14 성능 스키마 시스템 변수 테이블
29.12.15 성능 스키마 상태 변수 테이블
29.12.16 성능 스키마 스레드 풀 테이블
29.12.17 성능 스키마 방화벽 테이블
29.12.18 성능 스키마 키링 테이블
29.12.19 성능 스키마 클론 테이블
29.12.20 성능 스키마 요약 테이블
29.12.21 성능 스키마 텔레메트리 테이블
29.12.22 성능 스키마 기타 테이블
29.13 성능 스키마 옵션 및 변수 참조
29.14 성능 스키마 명령 옵션
29.15 성능 스키마 시스템 변수
29.16 성능 스키마 상태 변수
29.17 성능 스키마 메모리 할당 모델
29.18 성능 스키마와 플러그인
29.19 성능 스키마를 사용하여 문제 진단하기
29.19.1 성능 스키마를 사용한 쿼리 프로파일링
29.19.2 부모 이벤트 정보 얻기
29.20 성능 스키마에 대한 제한 사항
MySQL 성능 스키마는 MySQL 서버 실행을 낮은 수준에서 모니터링하기 위한 기능입니다. 성능 스키마는 특히 다음과 같은 특성을 가지고 있습니다:
성능 스키마
성능 스키마는 서버의 내부 실행을 런타임에 검사할 수 있는 수단을 제공합니다. 이것은 PERFORMANCE_SCHEMA PERFORMANCE_SCHEMA 스토리지 엔진과 performance_schema 데이터베이스를 사용하여 구현됩니다. 성능 스키마는 주로 성능 데이터에 중점을 두고 있습니다. 이것은 메타데이터 검사를 위한 INFORMATION_SCHEMA와는 구별됩니다.
성능 스키마는 서버 이벤트를 모니터링합니다. “이벤트”란 서버가 시간을 소모하며 타이밍 정보를 수집할 수 있도록 계측된 모든 작업을 정의됩니다. 대개 이벤트는 함수 호출, 운영 체제를 위한 대기, SQL 문 실행의 단계(예: 파싱 또는 정렬), 또는 전체 문 또는 문 그룹이 될 수 있습니다. 이벤트 수집은 서버 및 여러 스토리지 엔진에 대한 동기화 호출(예: 뮤텍스), 파일 및 테이블 I/O, 테이블 잠금 등에 대한 정보에 접근할 수 있도록 합니다.
성능 스키마 이벤트는 서버의 바이너리 로그에 기록된 이벤트(데이터 수정 설명) 및 이벤트 스케줄러 이벤트(저장된 프로그램의 일종)와는 다릅니다. 성능 스키마 이벤트는 특정 MySQL 서버 인스턴스에 특화되어 있습니다. 성능 스키마 테이블은 서버에 로컬로 간주되며, 이들에 대한 변경 사항은 복제되거나 바이너리 로그에 기록되지 않습니다.
현재 이벤트와 이벤트 이력 및 요약이 제공됩니다. 이를 통해 계측된 활동이 몇 번 수행되었는지와 그에 소요된 시간을 확인할 수 있습니다. 이벤트 정보는 특정 스레드의 활동이나 뮤텍스 또는 파일과 같은 특정 객체와 관련된 활동을 제공합니다.
PERFORMANCE_SCHEMA PERFORMANCE_SCHEMA 스토리지 엔진은 서버 소스 코드의 “계측 포인트”를 사용하여 이벤트 데이터를 수집합니다. 수집된 이벤트는 performance_schema 데이터베이스의 테이블에 저장됩니다. 이러한 테이블은 다른 테이블처럼 SELECT 문을 사용하여 쿼리할 수 있습니다.
Performance Schema 구성은 SQL 문을 통해 performance_schema 데이터베이스의 테이블을 업데이트하여 동적으로 수정할 수 있습니다. 구성 변경은 데이터 수집에 즉시 영향을 미칩니다.
Performance Schema의 테이블은 메모리 내 테이블로, 지속적인 디스크 저장소를 사용하지 않습니다. 내용은 서버 시작 시 다시 채워지고 서버 종료 시 폐기됩니다.
모니터링은 MySQL이 지원하는 모든 플랫폼에서 가능합니다. 일부 제한 사항이 적용될 수 있습니다: 타이머의 유형은 플랫폼마다 다를 수 있습니다. 스토리지 엔진에 적용되는 도구는 모든 스토리지 엔진에 대해 구현되지 않을 수 있습니다. 각 서드파티 엔진의 계측은 엔진 유지 관리자의 책임입니다. 또한 섹션 29.20, “Performance Schema에 대한 제한”을 참조하십시오.
데이터 수집은 계측을 추가하기 위해 서버 소스 코드를 수정하여 구현됩니다. 복제 또는 이벤트 스케줄러와 같은 다른 기능과 달리 Performance Schema와 관련된 별도의 스레드는 없습니다.
Performance Schema는 서버 성능에 미치는 영향을 최소화하면서 서버 실행에 대한 유용한 정보에 접근할 수 있도록 설계되었습니다. 구현은 다음과 같은 설계 목표를 따릅니다:
- Performance Schema를 활성화해도 서버 동작에 변화가 없습니다. 예를 들어, 스레드 스케줄링이 변경되지 않으며, 쿼리 실행 계획(EXPLAIN)이 변경되지 않습니다.
- 서버 모니터링은 매우 적은 오버헤드로 지속적이고 방해 없이 발생합니다. Performance Schema를 활성화해도 서버가 사용 불가능해지지 않습니다. 파서는 변경되지 않았습니다. 새로운 키워드나 문장이 없습니다.
Performance Schema가 내부적으로 실패하더라도 서버 코드의 실행은 정상적으로 진행됩니다.
이벤트 수집 중에 초기 처리와 이벤트 검색 중에 후속 처리를 수행하는 것 사이에 선택이 있을 때, 수집 속도를 높이는 것이 우선시됩니다. 이는 수집이 지속적으로 진행되는 반면, 검색은 필요에 따라 이루어지며 아예 발생하지 않을 수도 있기 때문입니다.
대부분의 Performance Schema 테이블에는 인덱스가 있어 옵티마이저가 전체 테이블 스캔 외의 실행 계획에 접근할 수 있습니다. 자세한 내용은 섹션 10.2.4, “Performance Schema 쿼리 최적화” 섹션 10.2.4, “Performance Schema 쿼리 최적화”를 참조하십시오.
새로운 계측 포인트를 추가하는 것은 쉽습니다.
계측은 버전 관리됩니다. 계측 구현이 변경되더라도 이전에 계측된 코드는 계속 작동합니다. 이는 서드파티 플러그인 개발자에게 이점이 되며, 최신 Performance Schema 변경 사항과 동기화하기 위해 각 플러그인을 업그레이드할 필요가 없습니다.
참고
MySQL sys 스키마는 Performance Schema에 의해 수집된 데이터에 편리하게 접근할 수 있는 객체 집합입니다. sys 스키마는 기본적으로 설치됩니다. 사용 지침은 제30장, MySQL sys 스키마 제30장, MySQL sys 스키마를 참조하십시오.