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.

Bonnes pratiques pour les performances et la mise à l'échelle de Aurora MySQL

Vous pouvez appliquer les bonnes pratiques suivantes afin d'améliorer les performances et la capacité de mise à l'échelle de vos clusters Aurora MySQL.

Utilisation de classes d'instances T pour le développement et les tests

Les instances Amazon Aurora MySQL qui utilisent les classes d'instance de base de données db.t2, db.t3 ou db.t4g sont particulièrement bien adaptées aux applications qui ne peuvent pas prendre en charge une charge de travail élevée de façon prolongée. Les instances T sont conçues pour offrir des performances de base modérées et la possibilité d'émettre en rafale pour atteindre des performances nettement supérieures si votre charge de travail l'exige. Elles sont prévues pour des charges de travail qui n'utilisent pas souvent ou de manière continue l'intégralité de l'UC, mais qui ont parfois besoin d'émettre en rafale. Nous recommandons d'utiliser les classes d'instance de base de données T uniquement pour les serveurs de développement et de test, ou pour d'autres serveurs non dédiés à la production. Pour plus d'informations sur les classes d'instances T, consultez Instances de performance à capacité extensible.

Si votre cluster Aurora est supérieur à 40 To, n'utilisez pas les classes d'instance T. Lorsque votre base de données contient un volume important de données, la surcharge de mémoire pour la gestion des objets du schéma peut dépasser la capacité d'une instance T.

N'activez pas le schéma de performance MySQL sur des instances T Amazon Aurora MySQL. S'il est activé, l'instance risque de manquer de mémoire.

Lorsque vous utilisez une instance T en tant qu'instance de base de données dans un cluster de base de données Aurora MySQL, nous vous recommandons la procédure suivante :

Optimisation des requêtes de jointure indexées Aurora MySQL avec lecture anticipée asynchrone des clés

Aurora MySQL peut utiliser la fonctionnalité de lecture anticipée asynchrone des clés (AKP) pour améliorer les performances des requêtes qui joignent des tables par le biais des index. Cette fonction améliore les performances en anticipant les lignes nécessaires à l'exécution des requêtes dans lesquelles une requête JOIN exige l'utilisation de l'algorithme Join d'accès par lots aux clés (Batched Key Access ou BKA) et des fonctions d'optimisation de la lecture multiplage (Multi-Range Read ou MRR). Pour plus d'informations sur BKA et MRR, consultez Block Nested-Loop and Batched Key Access Joins et Multi-Range Read Optimization dans la documentation MySQL.

Pour profiter de la fonction AKP, une requête doit utiliser à la fois BKA et MRR. Une telle requête se produit normalement lorsque la clause JOIN d'une requête utilise un index secondaire, mais nécessite également quelques colonnes pour l'index principal. Par exemple, vous pouvez utiliser AKP lorsque la clause JOIN représente une équijointure sur les valeurs d'index entre une petite table externe et une grande table interne, et que l'index de la grande table est très sélectif. AKP fonctionne en association avec BKA et MRR pour procéder à une recherche d'index secondaire à principal pendant l'évaluation de la clause JOIN. AKP identifie les lignes nécessaires pour exécuter la requête pendant l'évaluation de la clause JOIN. Elle utilise ensuite un thread d'arrière-plan pour charger de manière asynchrone des pages contenant ces lignes en mémoire avant d'exécuter la requête.

La lecture anticipée asynchrone des clés (AKP) est disponible pour Aurora MySQL versions 2.10 et ultérieures et version 3. Pour de plus amples informations sur les versions d'Aurora MySQL, veuillez consulter Mises à jour du moteur de base de données pour Amazon Aurora My SQL.

Activation de la lecture anticipée asynchrone des clés

Vous pouvez activer la fonction AKP en paramétrant aurora_use_key_prefetch, une variable de serveur MySQL, sur on. Par défaut, cette valeur indique on. Néanmoins, l'AKP ne peut pas être activée tant que l'algorithme de jointure BKA n'a pas été activé et que la fonctionnalité MRR basée sur le coût n'a pas été désactivée. Pour cela, vous devez spécifier les valeurs suivantes pour optimizer_switch, une variable du serveur MySQL :

Actuellement, vous pouvez uniquement configurer ces valeurs au niveau de la session. L'exemple suivant illustre la configuration de ces valeurs de manière à activer AKP pour la session en cours en exécutant les instructions SET.

mysql> set @@session.aurora_use_key_prefetch=on;
mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off';

De la même manière, vous pouvez utiliser des instructions SET pour désactiver la fonction AKP et l'algorithme Join BKA, et réactiver la fonctionnalité MRR basée sur le coût pour la session actuelle, comme indiqué dans l'exemple suivant.

mysql> set @@session.aurora_use_key_prefetch=off;
mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on';

Pour plus d'informations sur les commutateurs d'optimiseur batched_key_access et mrr_cost_based, consultez Switchable Optimizations dans la documentation MySQL.

Optimisation des requêtes pour la lecture anticipée asynchrone des clés

Vous pouvez confirmer si une requête doit pouvoir profiter des avantages de la fonction AKP. Pour cela, utilisez l'instruction EXPLAIN afin de profiler la requête avant de l'exécuter. L'instruction EXPLAIN fournit des informations sur le plan d'exécution à utiliser pour une requête déterminée.

Dans la sortie pour l'instruction EXPLAIN, la colonne Extra décrit les informations supplémentaires comprises avec le plan d'exécution. Si la fonction AKP s'applique à une table utilisée dans la requête, cette colonne inclut l'une des valeurs suivantes :

L'exemple suivant présente l'utilisation de l'instruction EXPLAIN pour visualiser le plan d'exécution d'une requête qui peut bénéficier d'AKP.

mysql> explain select sql_no_cache
    ->     ps_partkey,
    ->     sum(ps_supplycost * ps_availqty) as value
    -> from
    ->     partsupp,
    ->     supplier,
    ->     nation
    -> where
    ->     ps_suppkey = s_suppkey
    ->     and s_nationkey = n_nationkey
    ->     and n_name = 'ETHIOPIA'
    -> group by
    ->     ps_partkey having
    ->         sum(ps_supplycost * ps_availqty) > (
    ->             select
    ->                 sum(ps_supplycost * ps_availqty) * 0.0000003333
    ->             from
    ->                 partsupp,
    ->                 supplier,
    ->                 nation
    ->             where
    ->                 ps_suppkey = s_suppkey
    ->                 and s_nationkey = n_nationkey
    ->                 and n_name = 'ETHIOPIA'
    ->         )
    -> order by
    ->     value desc;
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
| id | select_type | table    | type | possible_keys         | key           | key_len | ref                              | rows | filtered | Extra                                                       |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
|  1 | PRIMARY     | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where; Using temporary; Using filesort                |
|  1 | PRIMARY     | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  1 | PRIMARY     | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
|  2 | SUBQUERY    | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where                                                 |
|  2 | SUBQUERY    | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  2 | SUBQUERY    | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
6 rows in set, 1 warning (0.00 sec)

Pour plus d'informations sur le format de sortie EXPLAIN, consultez Format de sortie EXPLAIN étendu (langue française non garantie) dans la documentation MySQL.

Optimisation des requêtes de jointure MySQL Aurora volumineuses avec des jointures de hachage

La jointure par hachage peut améliorer les performances de requêtes lorsque vous devez joindre une grande quantité de données au moyen d'une équijointure. Vous pouvez activer les jointures par hachage pour Aurora MySQL.

Une colonne de jointure par hachage peut être une expression complexe. Dans une colonne de jointure par hachage, vous pouvez effectuer des comparaisons dans les types de données des manières suivantes :

Les restrictions suivantes s'appliquent aux jointures par hachage pour Aurora MySQL :

Activation des jointures par hachage

Pour activer les jointures par hachage :

Les jointures par hachage sont activées par défaut dans Aurora MySQL version 3 et désactivées par défaut dans Aurora MySQL version 2. L'exemple suivant montre comment activer les jointures par hachage pour Aurora MySQL version 3. Vous pouvez commencer par publier l'instruction select @@optimizer_switch pour voir les autres paramètres présents dans la chaîne de paramètre SET. La mise à jour d'un paramètre du paramètre optimizer_switch n'efface ni ne modifie les autres paramètres.

mysql> SET optimizer_switch='block_nested_loop=on';

Avec ce paramètre, l'optimiseur choisit d'utiliser la jointure par hachage sur la base du coût, des caractéristiques de requête et de la disponibilité des ressources. Si l'estimation de coût est incorrecte, vous pouvez forcer l'optimiseur à choisir une jointure par hachage. Il suffit pour cela de paramétrer hash_join_cost_based, une variable de serveur MySQL, sur off. L'exemple suivant montre comment forcer l'optimiseur à choisir une jointure par hachage.

mysql> SET optimizer_switch='hash_join_cost_based=off';

Optimisation des requêtes pour les jointures par hachage

Pour savoir si une requête peut tirer parti d'une jointure par hachage, utilisez l'instruction EXPLAIN pour profiler la requête en premier. L'instruction EXPLAIN fournit des informations sur le plan d'exécution à utiliser pour une requête déterminée.

Dans la sortie pour l'instruction EXPLAIN, la colonne Extra décrit les informations supplémentaires comprises avec le plan d'exécution. Si une jointure par hachage s'applique aux tables utilisées dans la requête, cette colonne inclut des valeurs similaires aux suivantes :

L'exemple suivant présente l'utilisation d'EXPLAIN pour visualiser le plan d'exécution d'une requête de jointure par hachage.

mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2
    ->     WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1;
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra                                                          |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
|  1 | SIMPLE      | hj_small | ALL  | NULL          | NULL | NULL    | NULL |    6 | Using temporary; Using filesort                                |
|  1 | SIMPLE      | hj_big   | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where; Using join buffer (Hash Join Outer table hj_big)  |
|  1 | SIMPLE      | hj_big2  | ALL  | NULL          | NULL | NULL    | NULL |   15 | Using where; Using join buffer (Hash Join Inner table hj_big2) |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
3 rows in set (0.04 sec)

Dans la sortie, Hash Join Inner table représente la table utilisée pour construire la table de hachage, et Hash Join Outer table représente la table employée pour sonder la table de hachage.

Pour plus d'informations sur le format de sortie étendu d'EXPLAIN, consultez Extended EXPLAIN Output Format dans la documentation du produit MySQL.

Dans les versions 2.08 et supérieures d'Aurora MySQL, vous pouvez utiliser des indicateurs SQL pour déterminer si une requête utilise ou non la jointure de hachage, et quelles tables utiliser pour les côtés construction et sonde de la jointure. Pour plus d’informations, consultez Aurora Mes SQL conseils.

Utilisation d'Amazon Aurora pour dimensionner les lectures de votre base de données MySQL

Vous pouvez utiliser Amazon Aurora avec votre instance de base de données MySQL pour tirer parti des capacités de mise à l'échelle en lecture d'Amazon Aurora et développer la charge de travail en lecture de votre instance de base de données MySQL. Pour utiliser Aurora afin de mettre à l'échelle en lecture votre instance de base de données MySQL, créez un cluster de bases de données Aurora MySQL et faites-en un réplica en lecture de votre instance de base de données MySQL. Ensuite, connectez-vous au cluster Aurora MySQL pour traiter les requêtes en lecture. La base de données source peut être une instance de base de données RDS pour MySQL ou une base de données MySQL s'exécutant en dehors de Amazon RDS. Pour de plus amples informations, veuillez consulter Dimensionnement des lectures pour votre SQL base de données My avec Amazon Aurora.

Optimisation des opérations d'horodatage

Lorsque la valeur de la variable système time_zone est définie sur SYSTEM, chaque appel de fonction MySQL qui nécessite un calcul de fuseau horaire effectue un appel à la bibliothèque système. Lorsque vous exécutez des instructions SQL qui renvoient ou modifient de telles valeurs TIMESTAMP avec un taux de simultanéité élevé, vous pouvez constater une augmentation de la latence, de la contention des verrou et de l'utilisation du processeur. Pour plus d'informations, consultez time_zone dans la documentation MySQL.

Pour éviter ce comportement, nous vous recommandons de modifier la valeur du paramètre time_zone de cluster de base de données sur UTC. Pour de plus amples informations, veuillez consulter Modification des paramètres d'un groupe de paramètres de cluster de base de données dans Amazon Aurora.

Le paramètre time_zone est dynamique (il ne nécessite pas de redémarrage du serveur de base de données), mais la nouvelle valeur est utilisée uniquement pour les nouvelles connexions. Pour vous assurer que toutes les connexions sont mises à jour pour utiliser la nouvelle valeur time_zone, nous vous recommandons de recycler les connexions de votre application après avoir mis à jour le paramètre du cluster de bases de données.

Erreurs de dépassement de l'identifiant de l'index virtuel

Aurora MySQL limite les valeurs de l'index virtuel IDs à 8 bits pour éviter un problème causé par le format d'annulation dans MySQL. Si un index dépasse la limite d'ID d'index virtuel, il se peut que votre cluster ne soit pas disponible. Lorsqu'un index approche la limite d'ID d'index virtuel ou lorsque vous essayez de créer un index supérieur à la limite d'ID d'index virtuel, RDS peut générer un code d'erreur 63955 ou un code 63955 d'avertissement. Pour corriger une erreur de limite d'ID d'index virtuel, nous vous recommandons de recréer votre base de données avec un vidage et une restauration logiques.

Pour plus d'informations sur le vidage logique et la restauration pour Amazon Aurora MySQL, consultez Migrer de très grandes bases de données vers Amazon Aurora MySQL à l'aide de MyDumper et MyLoader. Pour plus d'informations sur l'accès aux journaux d'erreurs dans Amazon Aurora, consultezSurveillance des fichiers journaux Amazon Aurora.