MySQL 5.6 한글메뉴얼

22.15 문제를 진단하기위한 Performance Schema 사용

성능 스키마는 DBA가 "거친 추측 '이 아니라 실제로 측정하여 성능 튜닝을 할 수있는 도구입니다. 이 섹션에서는이 목적으로 성능 스키마를 사용하는 몇 가지 방법에 대해 설명합니다. 여기에서의 설명은 섹션 22.2.3.2 "성능 스키마 이벤트 필터링」 에서 설명하고있는 이벤트 필터링의 사용에 따라 달라집니다.

다음 예제에서는 성능 병목 현상 조사 등 반복되는 문제의 분석에 사용할 수있는 한 가지 방법을 보여줍니다. 시작하려면 성능이 "너무 늦게"로 간주되고 최적화가 필요한 반복 가능한 유스 케이스가 필요하며 모든 계측을 활성화해야합니다 (사전 필터링없이).

유스 케이스를 실행합니다.
성능 스키마 테이블을 사용하여 성능 문제의 원인을 분석합니다. 이 분석은 사후 필터링에 크게 의존합니다.
제외 문제 영역에 대해서는 해당 instrument를 해제합니다. 예를 들어, 문제가 특정 스토리지 엔진의 파일 I / O 관련하지 않는 것으로 분석으로 표시된 경우 엔진의 파일 I / O instrument를 해제합니다. 그 후 히스토리 및 요약 테이블을 잘라 지금까지 수집 된 이벤트를 제거합니다.
1 단계의 과정을 반복합니다.

반복 할 때마다 성능 스키마의 출력 특히 events_waits_history_long 테이블에 저장되는 무의미한 instrument에 의해 발생하는 '노이즈'가 줄어이 테이블이 고정 크기 인 경우, 당면 문제 분석 관련 데이터가 증가합니다.

반복마다 조사는 문제의 원인에 접근 해가는 것이며, 「시그널 / 노이즈 율 '이 개선되면서 분석이 쉬워집니다.
성능 병목 현상의 원인을 파악하면 다음과 같은 적절한 수정 조치를 취합니다.
- 서버 매개 변수 (캐시 크기, 메모리 등)을 조정합니다.
- 쿼리를 다른 방식으로 써 튜닝합니다.
- 데이터베이스 스키마 (테이블, 인덱스 등)를 조정합니다.
- 코드를 조정할 수 있습니다 (이것은 스토리지 엔진 또는 서버 개발자에게만 적용됩니다).
1 단계에서 다시 시작하여 성능에 변화의 효과를 확인합니다.

mutex_instances.LOCKED_BY_THREAD_ID 및 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 열 성능 병목 현상 또는 교착 상태의 조사에 매우 중요합니다. 이것은 다음과 같은 성능 스키마 계측에 의해 가능하게됩니다.

스레드 1은 상호 배타적 잠금을 대기하고 막히게합니다.
스레드가 무엇을 기다리고 있는지를 확인할 수 있습니다.
```
SELECT * FROM events_waits_current WHERE THREAD_ID = thread_1;
```
예를 들어, events_waits_current.OBJECT_INSTANCE_BEGIN 에있는 것처럼 스레드가 상호 배타적 잠금 A를 기다리는 것이 쿼리 결과에 표시됩니다.
상호 배타 락 A를 유지하고있는 thread를 확인할 수 있습니다.
```
SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
```
예를 들어, mutex_instances.LOCKED_BY_THREAD_ID 에있는 것처럼 상호 배타적 잠금 A를 보유하고있는이 스레드 2임을 쿼리 결과에 표시됩니다.
스레드 2가 무엇을 수행하고 있는지를 확인할 수 있습니다.
```
SELECT * FROM events_waits_current WHERE THREAD_ID = thread_2;
```