# io/table/sql/handler
El evento `io/table/sql/handler` se produce cuando el trabajo se ha delegado en un motor de almacenamiento.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.waitio.context.supported)
+ [Contexto](#ams-waits.waitio.context)
+ [Causas probables del aumento de las esperas](#ams-waits.waitio.causes)
+ [Acciones](#ams-waits.waitio.actions)
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL, versiones 2 y 3
## Contexto
El evento `io/table` indica una espera para acceder a una tabla. Este evento se produce independientemente de si los datos se almacenan en caché en el grupo de búferes o si se accede en el disco. El evento `io/table/sql/handler` indica un aumento de la actividad de la carga de trabajo.
Un *controlador* es una rutina especializada en un determinado tipo de datos o centrada en determinadas tareas especiales. Por ejemplo, un controlador de eventos recibe y procesa eventos y señales del sistema operativo o de una interfaz de usuario. Un controlador de memoria realiza tareas relacionadas con la memoria. Un controlador de entrada de archivos es una función que recibe una entrada de archivos y realiza tareas especiales en los datos, en función del contexto.
Vistas como, por ejemplo, `performance_schema.events_waits_current`, a menudo muestran `io/table/sql/handler` cuando la espera real es un evento de espera anidado como un bloqueo. Cuando la espera real no es `io/table/sql/handler`, Información sobre rendimiento informa del evento de espera anidado. Cuando Información sobre rendimiento informa `io/table/sql/handler`, representa el procesamiento de la solicitud de E/S por parte de InnoDB y no un evento de espera anidado oculto. Para obtener más información, consulte [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) en *MySQL Reference Manual*.
El evento `io/table/sql/handler` a menudo aparece en los principales eventos de espera con esperas de E/S como `io/aurora_redo_log_flush`.
## Causas probables del aumento de las esperas
En Información sobre rendimiento, los picos repentinos en el evento `io/table/sql/handler` indican un aumento de la actividad de la carga de trabajo. El aumento de la actividad significa un aumento de E/S.
Información sobre rendimiento filtra los ID de eventos de anidamiento y no informa de ninguna espera de `io/table/sql/handler` cuando el evento anidado subyacente sea una espera de bloqueo. Por ejemplo, si el evento de causa raíz es [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md), Información sobre rendimiento muestra esta espera en los eventos de espera principales y no `io/table/sql/handler`.
En vistas como, por ejemplo, `performance_schema.events_waits_current`, las esperas de `io/table/sql/handler` a menudo aparecen cuando la espera real es un evento de espera anidado como un bloqueo. Cuando la espera real difiere de `io/table/sql/handler`, Información sobre rendimiento busca la espera anidada e informa de la espera real en lugar de `io/table/sql/handler`. Cuando Información sobre rendimiento informa de `io/table/sql/handler`, la espera real es `io/table/sql/handler` y no un evento de espera anidado oculto. Para obtener más información, consulte [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) en *MySQL 5.7 Reference Manual*.
## Acciones
Si este evento de espera domina la actividad de la base de datos, no indica necesariamente un problema de rendimiento. Cuando la base de datos está activa, siempre hay un evento de espera activo. Solo debe actuar cuando el rendimiento se vea reducido.
Recomendamos diferentes acciones en función de los demás eventos de espera que vea.
**Topics**
+ [Identificar las sesiones y consultas que provocan los eventos](#ams-waits.waitio.actions.identify)
+ [Verificar la correlación con las métricas de contador de Información sobre rendimiento](#ams-waits.waitio.actions.filters)
+ [Verificar otros eventos de espera correlacionados](#ams-waits.waitio.actions.maintenance)
### Identificar las sesiones y consultas que provocan los eventos
Normalmente, las bases de datos con una carga de moderada a significativa tienen eventos de espera. Los eventos de espera pueden ser aceptables si el rendimiento es óptimo. Si el rendimiento no es óptimo, examine dónde pasa más tiempo la base de datos. Preste atención a los eventos de espera que contribuyen a la carga más alta y averigüe si puede optimizar la base de datos y la aplicación para reducirlos.
**Para buscar consultas SQL responsables de cargas elevadas**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Información sobre rendimiento**.
1. Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.
1. En el cuadro **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. En la parte inferior de la página, elija **Top SQL (SQL principal)**.
El gráfico enumera las consultas SQL responsables de la carga. Las que están en la parte superior de la lista son las más importantes. Para resolver un cuello de botella, céntrese en estas instrucciones.
Para obtener información general útil sobre la solución de problemas mediante Información sobre rendimiento, consulte la entrada de blog [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Verificar la correlación con las métricas de contador de Información sobre rendimiento
Verifique si hay métricas de contador de Información sobre rendimiento como `Innodb_rows_changed`. Si las métricas de contador están correlacionadas con `io/table/sql/handler`, siga los pasos que se indican a continuación:
1. En Información sobre rendimiento, busque las instrucciones SQL responsables del evento de espera principal `io/table/sql/handler`. Si es posible, optimice esta instrucción para que devuelva menos filas.
1. Recupere las tablas principales de las vistas `schema_table_statistics` y `x$schema_table_statistics`. Estas vistas muestran la cantidad de tiempo que empleó la tabla. Para obtener más información, consulte [The schema\$1table\$1statistics and x\$1schema\$1table\$1statistics Views](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html) en el *MySQL Reference Manual*.
De forma predeterminada, las filas se ordenan por tiempo de espera total descendente. Las tablas con más contención se muestran en primer lugar. La salida indica si el tiempo se dedica a lecturas, escrituras, recuperaciones, inserciones, actualizaciones o eliminaciones.
```
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 otros eventos de espera correlacionados
Si `synch/sxlock/innodb/btr_search_latch` y `io/table/sql/handler` contribuyen más a la anomalía de carga de la base de datos, verifique si la variable `innodb_adaptive_hash_index` está activada. Si lo está, considere la posibilidad de aumentar el valor del parámetro `innodb_adaptive_hash_index_parts`.
Si el índice hash adaptativo está desactivado, considere la posibilidad de activarlo. Para obtener más información acerca del índice hash adaptativo, consulte los siguientes recursos:
+ Artículo [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) en el sitio web de Percona.
+ [Adaptive Hash Index](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html) en el *MySQL Reference Manual*.
+ Artículo [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/) en el sitio web de Percona.
**nota**
El índice hash adaptativo no se admite en instancias de base de datos de lector de Aurora.
En algunos casos, el rendimiento puede ser deficiente en una instancia lectora cuando `synch/sxlock/innodb/btr_search_latch` y `io/table/sql/handler` son dominantes. Si es así, considere la posibilidad de redirigir la carga de trabajo temporalmente a la instancia de base de datos del escritor y active el índice hash adaptativo.