Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# io/table/sql/handler
L’événement `io/table/sql/handler` se produit lorsque la tâche a été déléguée à un moteur de stockage.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.waitio.context.supported)
+ [Contexte](#ams-waits.waitio.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#ams-waits.waitio.causes)
+ [Actions](#ams-waits.waitio.actions)
## Versions de moteur prises en charge
Ces informations relatives aux événements d’attente sont prises en charge pour les versions de moteur suivantes :
+ Aurora MySQL versions 2 et 3
## Contexte
L’événement `io/table` indique une attente avant d’accéder à une table. Cet événement se produit indépendamment du fait que les données soient mises en cache dans le groupe de mémoires tampons ou accessibles sur disque. L’événement `io/table/sql/handler` indique une augmentation de l’activité de la charge de travail.
Un *gestionnaire* est une routine spécialisée dans un certain type de données ou axée sur certaines tâches spécifiques. Par exemple, un gestionnaire d’événements reçoit et effectue la synthèse des événements et des signaux issus du système d’exploitation ou d’une interface utilisateur. Un gestionnaire de mémoire effectue des tâches liées à la mémoire. Un gestionnaire d’entrée de fichier est une fonction qui reçoit l’entrée de fichier et effectue des tâches spécifiques sur les données, en fonction du contexte.
Des vues telles que `performance_schema.events_waits_current` indiquent souvent `io/table/sql/handler` lorsque l’attente réelle est un événement d’attente imbriqué tel qu’un verrou. Lorsque l’attente réelle n’est pas `io/table/sql/handler`, Performance Insights signale l’événement d’attente imbriqué. Lorsque Performance Insights publie un rapport`io/table/sql/handler`, cela représente le traitement de la I/O demande par InnoDB et non un événement d'attente imbriqué masqué. Pour plus d’informations, consultez [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) dans le *Manuel de référence MySQL*.
L'`io/table/sql/handler`événement apparaît souvent dans les meilleurs événements d'attente avec des temps d' I/O attente tels que`io/aurora_redo_log_flush`.
## Causes probables de l’augmentation du nombre d’événements d’attente
Dans Performance Insights, des pics soudains de l’événement `io/table/sql/handler` indiquent une augmentation de l’activité de la charge de travail. Une activité accrue traduit une augmentation des I/O.
Performance Insights filtre l'événement d'imbrication IDs et ne signale pas d'`io/table/sql/handler`attente lorsque l'événement imbriqué sous-jacent est une attente bloquée. Par exemple, si l’événement de cause racine est [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md), Performance Insights affiche cette attente dans les principaux événements d’attente, et non `io/table/sql/handler`.
Dans des vues telles que `performance_schema.events_waits_current`, les attentes pour `io/table/sql/handler` apparaissent souvent lorsque l’attente réelle est un événement d’attente imbriqué tel qu’un verrou. Lorsque l’attente réelle diffère de `io/table/sql/handler`, Performance Insights recherche l’attente imbriquée et signale l’attente réelle plutôt que `io/table/sql/handler`. Lorsque Performance Insights signale `io/table/sql/handler`, l’attente réelle est `io/table/sql/handler`, et non un événement d’attente imbriqué masqué. Pour plus d’informations, consultez [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) dans le *Manuel de référence MySQL 5.7*.
## Actions
Si cet événement d’attente domine l’activité de la base de données, cela n’indique pas nécessairement un problème de performances. Un événement d’attente est toujours en tête lorsque la base de données est active. Vous ne devez intervenir qu’en cas de dégradation des performances.
Nous recommandons différentes actions en fonction des autres événement d’attente que vous voyez.
**Topics**
+ [Identifier les sessions et les requêtes à l’origine des événements](#ams-waits.waitio.actions.identify)
+ [Vérifier une éventuelle corrélation avec les métriques de compteur Performance Insights](#ams-waits.waitio.actions.filters)
+ [Rechercher d’autres événements d’attente corrélés](#ams-waits.waitio.actions.maintenance)
### Identifier les sessions et les requêtes à l’origine des événements
En règle générale, les bases de données à charge modérée à importante présentent des événements d’attente. Les événements d’attente peuvent être acceptables si les performances sont optimales. Si les performances ne sont pas optimales, voyez où la base de données passe le plus de temps. Examinez les événements d’attente qui contribuent à la charge la plus élevée et voyez si vous pouvez optimiser la base de données et l’application afin de réduire ces événements.
**Pour rechercher les requêtes SQL responsables d’une charge élevée**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Performance Insights**.
1. Choisissez une instance de base de données. Le tableau de bord Performance Insights s’affiche pour cette instance de base de données.
1. Dans le graphique **Database load (Charge de base de données)**, choisissez **Slice by wait (Tranche par attente)**.
1. Au bas de la page, choisissez **Top SQL (Principaux éléments SQL)**.
Le graphique répertorie les requêtes SQL responsables de la charge. Les requêtes situées en haut de la liste sont les plus responsables. Pour résoudre un goulet d’étranglement, concentrez-vous sur ces instructions.
Pour une présentation de la résolution des problèmes à l’aide de Performance Insights, consultez le billet de blog [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Vérifier une éventuelle corrélation avec les métriques de compteur Performance Insights
Vérifiez les métriques de compteur Performance Insights telles que `Innodb_rows_changed`. Si les métriques de compteur sont corrélées avec `io/table/sql/handler`, procédez comme suit :
1. Dans Performance Insights, recherchez les instructions SQL prenant en compte le principal événement d’attente `io/table/sql/handler`. Si possible, optimisez cette instruction de manière à ce qu’elle renvoie moins de lignes.
1. Récupérez les tables principales des vues `schema_table_statistics` et `x$schema_table_statistics`. Ces vues indiquent le temps passé par table. Pour plus d’informations, consultez [The schema\$1table\$1statistics and x\$1schema\$1table\$1statistics Views](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html) dans le *Manuel de référence MySQL*.
Par défaut, les lignes sont triées en fonction du temps d’attente total décroissant. Les tables présentant le plus de contention apparaissent en premier. La sortie indique si le temps concerne des lectures, écritures, extractions, insertions, mises à jour ou suppressions.
```
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)
```
### Rechercher d’autres événements d’attente corrélés
Si `synch/sxlock/innodb/btr_search_latch` et `io/table/sql/handler` contribuent le plus à l’anomalie de charge de base de données, vérifiez si la variable `innodb_adaptive_hash_index` est activée. Si tel est le cas, pensez à augmenter la valeur du paramètre `innodb_adaptive_hash_index_parts`.
Si l’index de hachage adaptatif est désactivé, pensez à l’activer. Pour en savoir plus sur l’index de hachage adaptatif MySQL, consultez les ressources suivantes :
+ Article [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) sur le site Percona
+ [Adaptive Hash Index](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html) dans le*Manuel de référence MySQL*
+ Article [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/) sur le site Percona
**Note**
L’index de hachage adaptatif n’est pas pris en charge par les instances de base de données du lecteur Aurora.
Dans certains cas, les performances peuvent être médiocres sur une instance en lecture lorsque `synch/sxlock/innodb/btr_search_latch` et `io/table/sql/handler` sont dominants. Si tel est le cas, pensez à rediriger temporairement la charge de travail vers l’instance de base de données d’enregistreur et à activer l’index de hachage adaptatif.