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.

Conseils pour le réglage des requêtes

Une fois que vous avez identifié les requêtes problématiques dans votre charge de travail, chaque requête doit être réglée. Suivez les instructions ci-dessous concernant le réglage pour optimiser l'efficacité de votre charge de travail.

Réduire le nombre de lignes analysées

Aussi simple que cela puisse paraître, c'est un excellent conseil à suivre lorsque vous réglez des requêtes. Utilisez l'instruction EXPLAIN et examinez la colonne des lignes pour voir combien de lignes l'optimiseur analyse à chaque jointure. Essayez de réduire le nombre de lignes analysées en créant un index optimal, puis expliquez à nouveau votre requête pour confirmer votre travail. Pour plus d’informations, consultez la documentation MySQL.

Si vous utilisez des tables partitionnées, interrogez-les toujours avec la clause WHERE qui permet l'élagage de partition afin que l'optimiseur n'ait pas à analyser chacune d'elles. Si votre clause WHERE contient une constante pour la colonne partitionnée, l'optimiseur sait quelle partition rechercher, ce qui améliore l'efficacité de votre requête.

Un autre aspect de ce conseil est la conception de votre base de données. Moins il y a de tables dans votre requête, plus elle sera rapide. Si vous pouvez dénormaliser la conception de votre base de données, vous pouvez faire en sorte que l'optimiseur analyse moins de lignes, et ainsi améliorer les performances des requêtes.

Réduire l'utilisation des tables temporaires et les tables temporaires sur disque

L'optimiseur Aurora compatible MySQL crée des tables temporaires à la fois sur la RAM et sur le disque s'il ne peut pas obtenir les résultats souhaités de votre requête directement à partir des index. Par conséquent, une grande partie du réglage consiste à disposer des bons index desservant votre charge de travail. Toutefois, il se peut que certaines requêtes de votre charge de travail ne puissent pas reposer uniquement sur des index. Certaines opérations peuvent donc être effectuées dans un fichier temporaire. Cela ne pose pas de problème tant que vous les limitez au minimum et que vous veillez à ce que très peu de tables soient créées sur le disque. MySQL crée des tables de disque lorsque la taille de la table temporaire est trop grande pour être stockée en mémoire. La logique utilisée par MySQL pour vérifier la taille de la table temporaire interne est la plus petite des deux valeurs de variable tmp_table_size et. max-heap-table-size Vous pouvez régler ces variables pour obtenir une valeur optimale en fonction de votre charge de travail. Ainsi, dans les cas où vous ne pouvez pas empêcher l'installation de tables temporaires, vous ne les transférez sur disque qu'en de rares occasions.

Éviter de trier des fichiers

Si votre charge de travail comporte beaucoup de requêtes ORDER BY, le meilleur moyen de les résoudre est d'utiliser les bons index sur vos tables. Assurez-vous que vos index à colonnes multiples sont bien conçus pour éviter le tri dans des fichiers. Le tri ne peut pas être effectué sur une colonne si les colonnes précédentes ne sont pas analysées avec des constantes (in, >, <, != et BETWEEN n'autoriseront pas le tri dans la colonne suivante à droite). La méthode de tri optimale dans MySQL consiste à placer un index à colonnes multiples qui positionne les colonnes contenant les valeurs constantes fournies dans la requête à gauche de la colonne de tri dans une structure contiguë. Si, en dernier ressort, votre requête ne peut pas renvoyer de résultats sans tri de fichiers, déplacez le tri vers l'application.

Éviter d'exécuter des requêtes d'agrégation en cas de forte simultanéité

Votre charge de travail peut comporter un petit nombre de requêtes d'agrégation pour répondre à certaines fonctionnalités de votre application. Ce cas d'utilisation exige une grande prudence. Le moteur InnoDB est conçu pour des charges de traitement des transactions en ligne (OLTP) appropriées, mais même quelques requêtes groupées en cas de simultanéité élevée peuvent être très lourdes pour le processeur et peuvent rapidement dégrader les performances de votre cluster. Pour résoudre les cas d'utilisation où vous avez besoin d'ensembles de résultats agrégés, agrégez préalablement les données dans des tableaux prêts à être lus afin d'éviter tout regroupement par requêtes.

Tester la simultanéité de vos requêtes

Lorsque vous réglez des requêtes individuelles, n'oubliez pas que ces requêtes s'exécutent simultanément sur plusieurs v CPUs dans Aurora MySQL compatible. Votre requête peut s'exécuter en quelques millisecondes dans votre environnement de test en une seule exécution. Mais ce n'est pas tout. Assurez-vous de tester votre requête avec le niveau de simultanéité attendu sur votre cluster de production et de comparer ses performances. Ne mettez la requête en production que lorsqu'elle répond à vos objectifs de simultanéité. Assurez-vous d'utiliser l'optimiseur hint sql_no_cache dans vos scripts de test afin d'éviter de récupérer les résultats depuis le cache. Vous pouvez utiliser des outils tels que mysqlslap pour effectuer le test simultanément et comparer les résultats.