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.

# synch/sxlock/innodb/hash\$1verrous de table
<a name="ams-waits.sx-lock-hash-table-locks"></a>

L’événement `synch/sxlock/innodb/hash_table_locks` se produit lorsque des pages introuvables dans le groupe de mémoires tampons doivent être lues à partir d’un fichier.

**Topics**
+ [Versions de moteur prises en charge](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Contexte](#ams-waits.sx-lock-hash-table-locks.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#ams-waits.sx-lock-hash-table-locks.causes)
+ [Actions](#ams-waits.sx-lock-hash-table-locks.actions)

## Versions de moteur prises en charge
<a name="ams-waits.sx-lock-hash-table-locks.context.supported"></a>

Ces informations relatives aux événements d’attente sont prises en charge dans les versions suivantes :
+ Aurora MySQL versions 2 et 3

## Contexte
<a name="ams-waits.sx-lock-hash-table-locks.context"></a>

L’événement `synch/sxlock/innodb/hash_table_locks` indique qu’une charge de travail accède fréquemment à des données qui ne sont pas stockées dans le groupe de mémoires tampons. Cet événement d’attente est associé à des ajouts de nouvelles pages et expulsions d’anciennes données du groupe de mémoires tampons. Les données stockées dans le groupe de mémoires tampons correspondant aux anciennes et nouvelles données doivent être mises en cache pour permettre l’expulsion des anciennes pages et la mise en cache des nouvelles pages. MySQL utilise un algorithme LRU (Last Recently Used) pour expulser les pages du groupe de mémoires tampons. La charge de travail tente d’accéder aux données qui n’ont pas été chargées dans le groupe de mémoires tampons ou aux données qui ont été expulsées de ce dernier.

Cet événement d’attente se produit lorsque la charge de travail doit accéder aux données de fichiers sur disque ou lorsque des blocs sont libérés ou ajoutés à la liste LRU du groupe de mémoires tampons. Ces opérations attendent d’obtenir un verrou partagé exclu (SX-Lock). Ce verrou SX-Lock est utilisé pour la synchronisation sur la *table de hachage*, qui est une table en mémoire conçue pour améliorer les performances d’accès au groupe de mémoires tampons.

Pour plus d’informations, consultez [Buffering and Caching](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html) dans la documentation MySQL.

## Causes probables de l’augmentation du nombre d’événements d’attente
<a name="ams-waits.sx-lock-hash-table-locks.causes"></a>

Lorsque l’événement d’attente `synch/sxlock/innodb/hash_table_locks` se produit plus souvent qu’à l’accoutumée, indiquant un possible problème de performance, les causes sont généralement les suivantes :

**Groupe de mémoires tampons sous-dimensionné**  
La taille du groupe de mémoires tampons est insuffisante pour conserver en mémoire toutes les pages fréquemment consultées.

**Charge de travail importante**  
La charge de travail entraîne de fréquentes expulsions et le rechargement de pages de données dans le cache de tampon.

**Erreurs de lecture des pages**  
Le groupe de mémoires tampons présente des erreurs de lectures de pages, ce qui peut indiquer une corruption des données.

## Actions
<a name="ams-waits.sx-lock-hash-table-locks.actions"></a>

Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.

**Topics**
+ [Augmentez la taille du groupe de mémoires tampons](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [Améliorer les modèles d’accès aux données](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [Réduire ou éviter les analyses de table entière](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [Rechercher une éventuelle corruption des pages dans les journaux d’erreurs](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)

### Augmentez la taille du groupe de mémoires tampons
<a name="ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size"></a>

Assurez-vous que le groupe de mémoires tampons est correctement dimensionné pour la charge de travail. Pour ce faire, vous pouvez vérifier le taux d’accès au cache du groupe de mémoires tampons. En règle générale, si la valeur est inférieure à 95 %, envisagez d’augmenter la taille du groupe de mémoires tampons. Un groupe de mémoires tampons plus important peut conserver les pages fréquemment consultées en mémoire plus longtemps. Pour augmenter la taille du groupe de mémoires tampons, modifiez la valeur du paramètre `innodb_buffer_pool_size`. La valeur par défaut de ce paramètre dépend de la taille de la classe d’instance de base de données. Pour plus d’informations, consultez [Bonnes pratiques relatives à la configuration de base de données Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/).

### Améliorer les modèles d’accès aux données
<a name="ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns"></a>

Vérifiez les requêtes affectées par cette attente ainsi que leurs plans d’exécution. Pensez à améliorer les modèles d’accès aux données. Par exemple, si vous utilisez [mysqli\$1result::fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php), vous pouvez essayer d’augmenter la taille d’extraction du tableau.

Vous pouvez utiliser Performance Insights pour afficher les requêtes et les sessions susceptibles d’entraîner l’événement d’attente `synch/sxlock/innodb/hash_table_locks`.

**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 utile du dépannage à l'aide de Performance Insights, consultez le billet de blog AWS consacré à la base de données [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).

### Réduire ou éviter les analyses de table entière
<a name="ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans"></a>

Surveillez votre charge de travail pour voir si elle exécute des analyses de table entière et, si tel est le cas, les réduire ou les éviter. Par exemple, vous pouvez surveiller des variables d’état telles que `Handler_read_rnd_next`. Pour plus d’informations, consultez [Server Status Variables](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next) dans la documentation MySQL.

### Rechercher une éventuelle corruption des pages dans les journaux d’erreurs
<a name="ams-waits.sx-lock-hash-table-locks.actions.check-error-logs"></a>

Vous pouvez consulter le journal mysql-error.log afin d’y détecter d’éventuels messages de corruption au moment du problème. Les messages à utiliser pour résoudre le problème se trouvent dans le journal des erreurs. Vous devrez peut-être recréer les objets signalés comme corrompus.