# io/table/sql/handler
`io/table/sql/handler` 이벤트는 작업을 스토리지 엔진에 작업이 위임했을 때 발생합니다.
**Topics**
+ [지원되는 엔진 버전](#ams-waits.waitio.context.supported)
+ [컨텍스트](#ams-waits.waitio.context)
+ [대기 증가의 가능한 원인](#ams-waits.waitio.causes)
+ [작업](#ams-waits.waitio.actions)
## 지원되는 엔진 버전
이 대기 이벤트 정보는 다음 엔진 버전에서 지원됩니다.
+ Aurora MySQL 버전 2 및 3
## 컨텍스트
`io/table` 이벤트는 테이블에 대한 액세스를 기다리고 있음을 나타냅니다. 이 이벤트는 데이터가 버퍼 풀에 캐시되는지 디스크에서 액세스되는지 관계없이 발생합니다. `io/table/sql/handler` 이벤트는 워크로드 활동의 증가를 나타냅니다.
*처리기(handler)*는 특정 유형의 데이터를 전문화하거나 특정 특수 작업에 중점을 둔 루틴입니다. 예를 들어 이벤트 처리기는 운영 체제 또는 사용자 인터페이스에서 이벤트와 신호를 수신하고 다이제스트합니다. 메모리 처리기는 메모리와 관련된 작업을 수행합니다. 파일 입력 처리기는 컨텍스트에 따라 파일 입력을 수신하고 데이터에 대한 특수 작업을 수행하는 기능입니다.
`performance_schema.events_waits_current`와 같은 보기는 실제 대기가 잠금과 같은 중첩된 대기 이벤트인 경우 `io/table/sql/handler`를 보여주는 경우가 많습니다. 실제 대기 시간이 `io/table/sql/handler`가 아닌 경우 성능 개선 도우미는 중첩된 대기 이벤트를 보고합니다. 성능 개선 도우미가 `io/table/sql/handler`를 보고하는 경우는 숨겨진 중첩 대기 이벤트가 아니라 I/O 요청의 InnoDB 처리를 나타냅니다. 자세한 내용은 *MySQL 참조 설명서*에서 [성능 스키마 원자 및 분자 이벤트](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html)를 참조하세요.
`io/table/sql/handler` 이벤트는 `io/aurora_redo_log_flush`와 같은 I/O 대기와 함께 상위 대기 이벤트에 나타나는 경우가 많습니다.
## 대기 증가의 가능한 원인
성능 개선 도우미에서 `io/table/sql/handler` 이벤트의 급격한 스파이크는 워크로드 활동의 증가를 나타냅니다. 활동 증가는 I/O 증가를 의미합니다.
성능 개선 도우미는 중첩 이벤트 ID를 필터링하고 기본 중첩 이벤트가 잠금 대기인 경우 `io/table/sql/handler` 대기를 보고하지 않습니다. 예를 들어 근본 원인 이벤트가 [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md)인 경우 성능 개선 도우미는 이 대기를 `io/table/sql/handler`가 아닌 상위 대기 이벤트에 표시합니다.
`performance_schema.events_waits_current`와 같은 보기에서 `io/table/sql/handler`의 대기는 실제 대기가 잠금과 같은 중첩된 대기 이벤트인 경우 나타나는 경우가 많습니다. 실제 대기가 `io/table/sql/handler`와 다른 경우 성능 개선 도우미는 중첩된 대기를 조회하고 `io/table/sql/handler`가 아닌 실제 대기를 보고합니다. 성능 개선 도우미가 `io/table/sql/handler`를 보고하는 경우 실제 대기는 숨겨진 중첩 대기 이벤트가 아닌 `io/table/sql/handler`입니다. 자세한 내용은 *MySQL 5.7 참조 설명서*에서 [성능 스키마 원자 및 분자 이벤트](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html)를 참조하세요.
## 작업
이 대기 이벤트가 데이터베이스 활동을 지배하는 경우 반드시 성능 문제를 나타내는 것은 아닙니다. 데이터베이스가 활성 상태일 때 대기 이벤트는 항상 맨 위에 있습니다. 성능이 저하될 때만 조치해야 합니다.
표시되는 다른 대기 이벤트에 따라 다른 작업을 권장합니다.
**Topics**
+ [이벤트를 일으키는 세션 및 쿼리 식별](#ams-waits.waitio.actions.identify)
+ [성능 개선 도우미 카운터 지표를 통해 상관관계 확인](#ams-waits.waitio.actions.filters)
+ [다른 상호 연관된 대기 이벤트 확인](#ams-waits.waitio.actions.maintenance)
### 이벤트를 일으키는 세션 및 쿼리 식별
일반적으로 보통 로드에서 중요 로드까지 있는 데이터베이스에는 대기 이벤트가 있습니다. 성능이 최적이면 대기 이벤트가 허용될 수 있습니다. 성능이 최적이 아닌 경우 데이터베이스가 가장 많은 시간을 소비하는 위치를 검사합니다. 가장 높은 로드를 일으키는 대기 이벤트를 살펴보고 데이터베이스와 애플리케이션을 최적화하여 이러한 이벤트를 줄일 수 있는지 확인합니다.
**높은 로드에 책임이 있는 SQL 쿼리를 찾으려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **Performance Insights**(성능 개선 도우미)를 선택합니다.
1. DB 인스턴스를 선택합니다. DB 인스턴스에 대한 성능 개선 도우미 대시보드가 표시됩니다.
1. **데이터베이스 로드(Database load)** 차트에서 **대기별 조각(Slice by wait)**을 선택합니다.
1. 페이지 하단에서 **상위 SQL(Top SQL)**을 선택합니다.
차트에는 로드에 책임이 있는 SQL 쿼리가 나열됩니다. 목록의 맨 위에 있는 쿼리가 가장 큰 책임이 있습니다. 병목 현상을 해결하려면 다음 명령문에 집중하세요.
성능 개선 도우미를 통한 문제 해결의 개요는 블로그 게시물, [성능 개선 도우미를 통해 Amazon Aurora MySQL 워크로드 분석](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)을 참조하세요.
### 성능 개선 도우미 카운터 지표를 통해 상관관계 확인
`Innodb_rows_changed`와 같은 성능 개선 도우미 카운터 지표를 확인합니다. 카운터 지표가 `io/table/sql/handler`와 상호 연관되어 있는 경우 다음 단계를 따르세요.
1. 성능 개선 도우미에서 `io/table/sql/handler` 상위 대기 이벤트에 해당하는 SQL 문을 찾습니다. 가능한 경우 더 적은 수의 행을 반환하도록 이 명령문을 최적화합니다.
1. `schema_table_statistics` 및 `x$schema_table_statistics` 보기에서 상위 테이블을 검색합니다. 이러한 보기는 테이블당 소요된 시간을 보여줍니다. 자세한 내용은 *MySQL 참조 설명서*에서 [schema\$1table\$1statistics 및 x\$1schema\$1table\$1statistics 보기](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html)를 참조하세요.
기본적으로 행은 총 대기 시간의 내림차순으로 정렬됩니다. 경합이 가장 많은 테이블이 먼저 표시됩니다. 출력은 읽기, 쓰기, 가져오기, 삽입, 업데이트 또는 삭제에 소요되는 시간 여부를 나타냅니다.
```
mysql> select * from sys.schema_table_statistics limit 1\G
*************************** 1. row ***************************
table_schema: read_only_db
table_name: sbtest41
total_latency: 54.11 m
rows_fetched: 6001557
fetch_latency: 39.14 m
rows_inserted: 14833
insert_latency: 5.78 m
rows_updated: 30470
update_latency: 5.39 m
rows_deleted: 14833
delete_latency: 3.81 m
io_read_requests: NULL
io_read: NULL
io_read_latency: NULL
io_write_requests: NULL
io_write: NULL
io_write_latency: NULL
io_misc_requests: NULL
io_misc_latency: NULL
1 row in set (0.11 sec)
```
### 다른 상호 연관된 대기 이벤트 확인
`synch/sxlock/innodb/btr_search_latch` 및 `io/table/sql/handler`가 DB 로드 이상에 가장 많이 기여하는 경우 `innodb_adaptive_hash_index` 변수가 활성화되어 있는지 확인합니다. 그렇다면 `innodb_adaptive_hash_index_parts` 파라미터 값을 늘리는 것이 좋습니다.
Adaptive Hash Index가 꺼져 있는 경우 켜는 것이 좋습니다. MySQL Adaptive Hash Index에 대한 자세한 내용은 다음 리소스를 참조하세요.
+ Percona 웹 사이트의 문서, [InnoDB의 Adaptive Hash Index가 내 워크로드에 적합한가요?](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload)
+ [MySQL 참조 설명서](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html)의 *Adaptive Hash Index*
+ Percona 웹 사이트의 문서, [MySQL InnoDB에서 경합: Semaphores 섹션의 유용한 정보](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/)
**참고**
Adaptive Hash Index는 Aurora 리더 DB 인스턴스에서 지원되지 않습니다.
경우에 따라 `synch/sxlock/innodb/btr_search_latch` 및 `io/table/sql/handler`가 지배적이면 리더 인스턴스에서 성능이 저하될 수 있습니다. 그렇다면 워크로드를 일시적으로 작성기 DB 인스턴스로 리디렉션하고 Adaptive Hash Index를 켜는 것이 좋습니다.