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.

Réglage des charges de travail d'écriture

L'implémentation de l'équilibrage de charge et la libération de l'instance d'enregistreur aideront votre charge de travail d'écriture à fournir de meilleures performances en cas de pics élevés. Pour obtenir de meilleures performances d'écriture en cas de simultanéité élevée, suivez ces étapes supplémentaires.

Déplacer l'intégrité référentielle dans la couche applicative

Bien que les contrôles de l'intégrité référentielle soient importants, l'hyperéchelle peut nuire à votre charge. Pour chaque écriture, des analyses supplémentaires doivent être effectuées avant que l'écriture elle-même ne soit exécutée, ce qui donne lieu à de mauvaises performances. Si votre application nécessite des contrôles d'intégrité stricts, intégrez-les dans la couche d'application pour éviter qu'ils ne limitent vos écritures.

Éviter d'utiliser des clés primaires lourdes

Faites en sorte que vos clés primaires restent légères. Le moteur de stockage InnoDB ajoute la clé primaire à tous les autres index que vous créez dans votre table. Lorsque votre clé primaire est volumineuse, la taille de l'index en sera affectée. Le stockage et la récupération des pages de données seront ralentis si la clé primaire est assez volumineuse. L'utilisation d'identifiants uniques universels comme clés primaires en est un exemple courant. Il ne s'agit pas d'une bonne approche si vous ciblez les performances dans un environnement à l'hyperéchelle.

Utiliser l'échange de partitions pour charger des données dans des tables partitionnées

Si vous écrivez de grands jeux de données dans des tables partitionnées, la combinaison de LOAD DATA FROM S3 et d'échange de partitions peut améliorer les performances, car la table principale n'est pas accessible pour les insertions. L'échange de partitions utilise un langage de définition de données (DDL) qui verrouille les métadonnées de votre table. Assurez-vous que cette opération est effectuée lorsque peu ou pas de requêtes sont exécutées sur la table afin que le DDL d'échange de partitions puisse obtenir le verrouillage des métadonnées sans attendre. L'échange lui-même ne prend que quelques millisecondes.

Supprimez les index inutilisés

InnoDB optimise ses plans de requêtes en fonction de l'évolution de vos données, et il est conseillé de vérifier les index inutilisés dans votre base de données et de les supprimer. Les index non utilisés consomment des E/S lorsque l'application écrit des données dans une table. Consultez la liste des index non utilisés et vérifiez qu'il ne s'agit pas d'index utilisés dans de rares situations, telles que les rapports trimestriels. Notez également que certains index sont utilisés pour appliquer l'unicité ou l'ordre et doivent également être pris en compte.

S'assurer que les anciennes versions de ligne sont correctement purgées

Dans l'implémentation du contrôle de simultanéité multiversion (MVCC) d'InnoDB, lorsqu'un enregistrement est modifié, la version actuelle (ancienne) des données modifiées est d'abord enregistrée sous la forme d'un enregistrement d'annulation dans un journal d'annulation. Une valeur de longueur de la liste d'historique (HLL) croissante indique que les threads de récupérateur de mémoire d'InnoDB (threads de purge) ne suivent pas le rythme de la charge de travail d'écriture ou que la purge est bloquée par une requête ou une transaction de longue durée. Lorsque le récupérateur de mémoire est bloqué ou retardé, la base de données peut développer un retard de purge important qui peut affecter négativement les performances des requêtes. Vous pouvez utiliser les recommandations suivantes pour optimiser le processus de purge.

S'assurer que la journalisation n'entraîne pas de conflits supplémentaires

Le journal des requêtes générales journalise les connexions et les déconnexions des clients, ainsi que toutes les instructions reçues par le serveur dans l'ordre de leur réception. Lorsqu'elle est activée, la journalisation est synchrone, ce qui peut entraîner une réduction importante des performances sur un système occupé. À moins que cela ne soit nécessaire, nous vous recommandons de désactiver le journal général.

Le journal des requêtes lentes enregistre les instructions qui ont pris plus de temps que le nombre de secondes d'exécution long_query_time, le réglage par défaut étant de 10 secondes. Lorsque le paramètre est défini sur 0, toutes les instructions sont journalisées de manière synchrone, ce qui peut affecter les performances des bases de données occupées.