MySQL 5.6 한글메뉴얼

22.2.3.2 성능 스키마 이벤트 필터링

이벤트는 생산자 / 소비자 방식으로 처리됩니다.

instrument 된 코드는 이벤트 소스에서 수집 된 이벤트를 생성합니다. setup_instruments 테이블은 이벤트를 수집 할 수있는 instrument, 그들이 활성화되어 있는지, 그리고 (활성화되어있는 인스트르먼트의 경우) 타이밍 정보를 수집할지 여부를 나열합니다.
```
mysql> SELECT * FROM setup_instruments;
+------------------------------------------------------------+---------+-------+
| NAME                                                       | ENABLED | TIMED |
+------------------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock                 | YES     | YES   |
| wait/synch/mutex/sql/LOCK_global_system_variables          | YES     | YES   |
| wait/synch/mutex/sql/LOCK_lock_db                          | YES     | YES   |
| wait/synch/mutex/sql/LOCK_manager                          | YES     | YES   |
...
```
setup_instruments 테이블은 이벤트 생성의 가장 기본적인 제어 형식을 제공합니다. 모니터되는 오브젝트와 스레드의 종류에 따라 이벤트 생성을 더욱 좁힐 수있는 섹션 22.2.3.3 "이벤트 사전 필터링" 에 설명 된대로 다른 테이블을 사용할 수 있습니다.

성능 스키마 테이블은 이벤트 대상에서 이벤트를 소비합니다. setup_consumers 테이블 이벤트 정보를 전송하는 전자 제품의 종류와 그들이 활성화되어 있는지 여부를 표시합니다.

mysql> SELECT * FROM setup_consumers;
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| events_stages_current          | NO      |
| events_stages_history          | NO      |
| events_stages_history_long     | NO      |
| events_statements_current      | YES     |
| events_statements_history      | NO      |
| events_statements_history_long | NO      |
| events_waits_current           | NO      |
| events_waits_history           | NO      |
| events_waits_history_long      | NO      |
| global_instrumentation         | YES     |
| thread_instrumentation         | YES     |
| statements_digest              | YES     |
+--------------------------------+---------+

필터링은 성능 모니터링의 다양한 단계에서 실행할 수 있습니다.

사전 필터링. 이것은 생산에서 특정 유형의 이벤트 만 수집하고 수집 된 이벤트가 특정 소비자 만 업데이트하도록 성능 스키마 구성을 변경하여 이루어집니다. 이렇게하려면 instrument 또는 소비자를 활성화 또는 비활성화합니다. 사전 필터링 성능 스키마에 의해 만들어진 모든 사용자에게 적용되는 글로벌 효과를가집니다.

사전 필터링을 사용하는 이유 :
- 오버 헤드를 줄이기 위해. 성능 스키마의 오버 헤드는 모든 instrument를 사용하고도 최소이어야하지만 더 축소 싶다고 생각할 수 있습니다. 또는 타이밍 이벤트에 관심이없고 타이밍 오버 헤드를 제거하기 위해 타이밍 코드를 해제하고 싶다고 생각합니다.
- 관심이없는 이벤트의 현재의 이벤트 또는 기록 테이블에 입력을 막기 위하여. 사전 필터링은 이러한 테이블에 유효한 instrument의 종류 행 인스턴스에 대해 많은 "여유"를 떠난다. 사전 필터링 파일 instrument만을 사용하는 경우, 비 파일 instrument의 줄은 수집되지 않습니다. 사후 필터링되지 않은 파일 이벤트가 수집 된 파일 이벤트 적은 행이 남아 있습니다.
- 특정 유형의 이벤트 테이블의 유지 보수를 피하기 위해. 소비자를 비활성화하면 서버는 소비자 대상의 유지 보수에 시간을 소비하지 않습니다. 예를 들어, 이벤트 기록에 관심이없는 경우 기록 테이블 소비자를 해제하여 성능을 향상시킬 수 있습니다.
사후 필터링. 여기에는 쿼리에서 성능 스키마 테이블에서 정보를 선택하는 WHERE 절을 사용하여 사용 가능한 이벤트 중 표시 할 것을 지정할 수 있습니다. 사후 필터링은 각 사용자가 사용 가능한 이벤트 중 관심있는 것을 선택하는 사용자 단위로 실행됩니다.

사후 필터링을 사용하는 이유 :
- 관심있는 이벤트 정보에 대해 개별 사용자의 결정을 피하기 위해.
- 사전 필터링의 사용에 부과되는 제한이 미리 모르는 경우에 성능 스키마를 사용하여 성능 문제를 조사하기 위하여.

다음 섹션에서는 사전 필터링에 대해 자세히 설명하고 필터링 조작으로 instrument와 소비자를 지정하기위한 지침을 제공합니다. 정보를 얻기위한 쿼리 작성 (사후 필터링) 내용은 섹션 22.3 "성능 스키마 쿼리" 를 참조하십시오.