# io/table/sql/handler
O evento `io/table/sql/handler` ocorre quando o trabalho foi delegado a um mecanismo de armazenamento.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.waitio.context.supported)
+ [Contexto](#ams-waits.waitio.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.waitio.causes)
+ [Ações](#ams-waits.waitio.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:
+ Aurora MySQL versões 2 e 3
## Contexto
O evento `io/table` indica uma espera pelo acesso a uma tabela. Esse evento ocorre não importa se os dados estão armazenados em cache no grupo de buffer ou acessados no disco. O evento `io/table/sql/handler` indica um aumento na atividade da workload.
Um *manipulador* é uma rotina especializada em um determinado tipo de dados ou focada em certas tarefas especiais. Por exemplo, um manipulador de eventos recebe e digere eventos e sinais provenientes do sistema operacional ou de uma interface de usuário. Um manipulador de memória realiza tarefas relacionadas a memória. Um manipulador de entrada de arquivo é uma função que recebe a entrada de arquivos e realiza tarefas especiais nos dados de acordo com o contexto.
Visualizações como `performance_schema.events_waits_current` muitas vezes indicam `io/table/sql/handler` quando a espera real é um evento de espera aninhado, como um bloqueio. Quando a espera real não é `io/table/sql/handler`, o Performance Insights relata o evento de espera aninhado. Quando o Performance Insights relata `io/table/sql/handler`, isso representa o processamento de InnoDB da solicitação de E/S e não um evento de espera aninhado oculto. Para saber mais, consulte o tópico sobre [Eventos "átomo" e "molécula" no Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html), no *Manual de referência do MySQL*.
O evento `io/table/sql/handler` costuma aparecer nos principais eventos de espera com esperas de E/S, como `io/aurora_redo_log_flush`.
## Possíveis causas do maior número de esperas
No Performance Insights, picos repentinos no evento `io/table/sql/handler` indicam aumento na atividade da workload. O aumento da atividade significa E/S elevada.
O Performance Insights filtra os IDs de eventos de aninhamento e não informa uma espera `io/table/sql/handler` quando o evento aninhado subjacente é uma espera de bloqueio. Por exemplo, se o evento da causa raiz for [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md), o Performance Insights exibirá essa espera nos principais eventos de espera, e não em `io/table/sql/handler`.
Em visualizações como `performance_schema.events_waits_current`, esperas por `io/table/sql/handler` geralmente aparecem quando a espera real é um evento de espera aninhado, como um bloqueio. Quando a espera real é diferente de `io/table/sql/handler`, o Performance Insights procura a espera aninhada e relata a espera real em vez de `io/table/sql/handler`. Quando o Performance Insights relata `io/table/sql/handler`, a espera real é `io/table/sql/handler`, e não um evento de espera aninhado oculto. Para saber mais, consulte o tópico sobre [Eventos "átomo" e "molécula" no Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html), no *Manual de referência do MySQL 5.7*.
## Ações
Se esse evento de espera domina a atividade do banco de dados, isso não indica necessariamente um problema de performance. Um evento de espera está sempre na parte superior quando o banco de dados está ativo. Você precisará reagir somente quando a performance piorar.
Recomendamos diferentes ações dependendo dos outros eventos de espera exibidos.
**Topics**
+ [Identificar as sessões e as consultas que estão causando os eventos](#ams-waits.waitio.actions.identify)
+ [Verifique se existe uma correlação com as métricas de contadores do Performance Insights](#ams-waits.waitio.actions.filters)
+ [Verificar se existem outros eventos de espera correlacionados](#ams-waits.waitio.actions.maintenance)
### Identificar as sessões e as consultas que estão causando os eventos
Em geral, bancos de dados com carga de moderada a significativa apresentam eventos de espera. Os eventos de espera podem ser aceitáveis quando a performance é ideal. Se a performance não for ideal, examine onde o banco de dados está passando a maior parte do tempo. Observe os eventos de espera que contribuem para a carga mais alta e descubra se é possível otimizar o banco de dados e a aplicação para reduzir esses eventos.
**Para localizar consultas SQL que são responsáveis pela carga alta**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Performance Insights**.
1. Escolha uma instância de banco de dados. O painel do Performance Insights é exibido para essa instância de banco de dados.
1. No gráfico **Database load** (Carga de banco de dados), escolha **Slice by wait** (Segmentar por espera).
1. Na parte inferior da página, escolha **Top SQL** (SQL principal).
O gráfico mostra as consultas SQL que são responsáveis pela carga. Os que estão no topo da lista são os mais responsáveis. Para solucionar um gargalo, concentre-se nessas instruções.
Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a Publicação no blog sobre como [Analisar workloads do Amazon Aurora MySQL com o Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Verifique se existe uma correlação com as métricas de contadores do Performance Insights
Verifique as métricas do contador do Performance Insights, como `Innodb_rows_changed`. Se as métricas de contadores estiverem correlacionadas com `io/table/sql/handler`, siga estas etapas:
1. No Performance Insights, procure as instruções SQL que representam o evento de espera principal `io/table/sql/handler`. Se possível, otimize essa instrução de forma que ela retorne menos linhas.
1. Recupere as principais tabelas das visualizações `schema_table_statistics` e `x$schema_table_statistics`. Essas visualizações mostram o tempo gasto por tabela. Para ter mais informações, consulte [As visualizações schema\$1table\$1statistics e x\$1schema\$1table\$1statistics](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html), no *Manual de referência do MySQL*.
Por padrão, as linhas são classificadas por tempo de espera total em ordem decrescente. Tabelas com mais disputa aparecem primeiro. A saída indica se o tempo é gasto em buscas, inserções, leituras, gravações, atualizações ou exclusões.
```
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)
```
### Verificar se existem outros eventos de espera correlacionados
Se `synch/sxlock/innodb/btr_search_latch` e `io/table/sql/handler` forem juntos os principais colaboradores para a anomalia de carga de banco de dados, verifique se a variável `innodb_adaptive_hash_index` está habilitada. Se estiver, considere aumentar o valor do parâmetro `innodb_adaptive_hash_index_parts`.
Se o Adaptive Hash Index estiver desabilitado, considere habilitá-lo. Para saber mais sobre o Adaptive Hash Index do MySQL, consulte os seguintes recursos:
+ O artigo [Is Adaptive Hash Index in InnoDB right for my workload?](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload), no site da Percona
+ [Adaptive Hash Index](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html), no *Manual de referência do MySQL*
+ O artigo [Contention in MySQL InnoDB: Useful Info From the Semaphores Section](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/), no site da Percona
**nota**
O Adaptive Hash Index não é compatível com instâncias de banco de dados de leitor do Aurora.
Em alguns casos, a performance pode ser ruim em uma instância de leitor quando `synch/sxlock/innodb/btr_search_latch` e `io/table/sql/handler` são dominantes. Em caso afirmativo, considere redirecionar a workload temporariamente à instância de banco de dados de gravador e habilitar o Adaptive Hash Index.