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. # Nouveau comportement de table temporaire dans Aurora MySQL version 3 Aurora MySQL version 3 gère les tables temporaires différemment des versions précédentes d’Aurora MySQL. Ce nouveau comportement est hérité de MySQL 8.0 Community Edition. Il existe deux types de tables temporaires qui peuvent être créées avec Aurora MySQL version 3 : + Tables temporaires internes (ou *implicites*) : créées par le moteur Aurora MySQL pour gérer des opérations telles que le tri, l'agrégation, les tables dérivées ou les expressions de table communes (CTEs). + Tables temporaires créées par l’utilisateur (ou *explicites*) : créées par le moteur Aurora MySQL lorsque vous utilisez l’instruction `CREATE TEMPORARY TABLE`. Il existe des considérations supplémentaires pour les tables temporaires internes et créées par l’utilisateur sur les instances de base de données de lecteur Aurora. Ces modifications sont présentées dans les sections suivantes. **Topics** + [Moteur de stockage pour tables temporaires internes (implicites)](#ams3-temptable-behavior-engine) + [Limitation de la taille des tables temporaires internes en mémoire](#ams3-temptable-behavior-limit) + [Atténuation des problèmes de remplissage pour les tables temporaires internes sur les réplicas Aurora](#ams3-temptable-behavior-mitigate) + [Optimisation du paramètre temptable\$1max\$1mmap sur les instances de base de données Aurora MySQL](#ams-optimize-temptable_max_mmap) + [Tables temporaires (explicites) créées par l’utilisateur sur les instances de base de données de lecteur](#ams3-temptable-behavior.user) + [Erreurs de création d’une table temporaire et atténuation](#ams3-temptable-behavior.errors) ## Moteur de stockage pour tables temporaires internes (implicites) Lors de la génération de jeux de résultats intermédiaires, Aurora MySQL tente initialement d’écrire dans des tables temporaires en mémoire. Cela peut échouer, en raison de types de données incompatibles ou de limites configurées. Si c’est le cas, la table temporaire est convertie en table temporaire sur disque plutôt que d’être conservée en mémoire. Pour plus d’informations, consultez [Internal Temporary Table Use in MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) dans la documentation MySQL. Dans Aurora MySQL version 3, le fonctionnement des tables temporaires internes est différent des versions précédentes d’Aurora MySQL. Pour ces tables temporaires, au lieu de choisir entre les moteurs de stockage InnoDB et MyISAM, vous avez maintenant le choix entre les moteurs de stockage `TempTable` et `MEMORY`. Avec le moteur de stockage `TempTable`, vous disposez d’un choix supplémentaire pour gérer certaines données. Les données affectées dépassent la capacité du groupe de mémoire qui contient toutes les tables temporaires internes de l’instance de base de données. Ces choix peuvent influencer les performances des requêtes qui génèrent des volumes élevés de données temporaires, par exemple lors de l’exécution d’agrégations telles que `GROUP BY` sur des tables volumineuses. **Astuce** Si votre charge de travail inclut des requêtes qui génèrent des tables temporaires internes, confirmez les performances de votre application avec cette modification en exécutant des définitions de points de référence et en surveillant les métriques liées aux performances. Dans certains cas, la quantité de données temporaires correspond à la capacité du groupe de mémoire `TempTable` ou est légèrement supérieure à cette dernière. Le cas échéant, nous vous recommandons d’utiliser le paramètre `TempTable` pour les tables temporaires internes et les fichiers mappés en mémoire pour conserver toutes les données excédentaires. Il s’agit de la valeur par défaut. Le moteur de stockage `TempTable` est le moteur par défaut. `TempTable` utilise un groupe de mémoire commun pour toutes les tables temporaires utilisant ce moteur, au lieu d’une limite de mémoire maximale par table. La taille de ce groupe de mémoire est spécifiée par le paramètre [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram). Elle est par défaut de 1 Gio sur les instances de base de données de 16 Gio de mémoire ou plus, et de 16 Mo sur les instances de base de données de moins de 16 Gio de mémoire. La taille du groupe de mémoire influe sur la consommation de mémoire au niveau de la session. Dans certains cas, lorsque vous utilisez le moteur de stockage `TempTable`, les données temporaires peuvent dépasser la taille du groupe de mémoire. Si tel est le cas, Aurora MySQL stocke les données de débordement à l’aide d’un mécanisme secondaire. Vous pouvez définir le paramètre [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) pour choisir si les données dépassent la taille des fichiers temporaires mappés en mémoire ou des tables temporaires internes InnoDB sur le disque. Les différents formats de données et les critères de dépassement de ces mécanismes de dépassement peuvent affecter les performances des requêtes. Pour ce faire, Ils influencent la quantité de données écrites sur disque et la demande de débit de stockage sur le disque. Aurora MySQL version 3 stocke les données de débordement de la manière suivante : + Sur l’instance de base de données d’enregistreur, les données qui débordent vers des tables temporaires internes InnoDB ou des fichiers temporaires mappés en mémoire se trouvent sur le stockage local de l’instance. + Sur les instances de base de données de lecteur, les données excédentaires se trouvent toujours dans des fichiers temporaires mappés en mémoire sur le stockage local. Les instances en lecture seule ne peuvent stocker aucune donnée sur le volume de cluster Aurora. Les paramètres de configuration associés aux tables temporaires internes s’appliquent différemment aux instances de lecteur et d’enregistreur sur votre cluster. + Sur les instances de lecteur, Aurora MySQL utilise toujours le moteur de stockage `TempTable`. + La taille par défaut de `temptable_max_mmap` est de 1 Gio, pour les instances de lecteur et d’enregistreur, quelle que soit la taille de la mémoire de l’instance de base de données. Vous pouvez ajuster cette valeur à la fois sur les instances d’enregistreur et de lecteur. + Définir `temptable_max_mmap` sur `0` désactive l’utilisation des fichiers temporaires mappés en mémoire sur les instances d’enregistreur. + Vous ne pouvez pas définir `temptable_max_mmap` sur `0` sur les instances de lecteur. **Note** Nous déconseillons l’utilisation du paramètre [temptable\$1use\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap). Il est devenu obsolète et sa prise en charge devrait être supprimée dans une future version de MySQL. ## Limitation de la taille des tables temporaires internes en mémoire Comme indiqué dans [Moteur de stockage pour tables temporaires internes (implicites)](#ams3-temptable-behavior-engine), vous pouvez contrôler les ressources de tables temporaires de manière globale en utilisant les paramètres [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) et [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap). Vous pouvez également limiter la taille de n’importe quelle table temporaire interne en mémoire en utilisant le paramètre de base de données [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size). Cette limite vise à empêcher les requêtes individuelles de consommer une quantité excessive de ressources de tables temporaires globales, ce qui peut affecter les performances de requêtes simultanées nécessitant ces ressources. Le paramètre `tmp_table_size` définit la taille maximale des tables temporaires créées par le moteur de stockage `MEMORY` dans Aurora MySQL version 3. Dans Aurora MySQL version 3.04 ou ultérieure, `tmp_table_size` définit également la taille maximale des tables temporaires créées par le moteur de stockage `TempTable` quand le paramètre de base de données `aurora_tmptable_enable_per_table_limit` a pour valeur `ON`. Ce comportement est désactivé par défaut (`OFF`), ce qui constitue le même comportement que dans Aurora MySQL version 3.03 et versions antérieures. + Quand `aurora_tmptable_enable_per_table_limit` a pour valeur `OFF`, `tmp_table_size` n’est pas pris en compte pour les tables temporaires internes en mémoire créées par le moteur de stockage `TempTable`. Cependant, la limite globale des ressources `TempTable` s’applique toujours. Aurora MySQL a le comportement suivant lorsque la limite globale des ressources `TempTable` est atteinte : + Instances de base de données d’enregistreur : Aurora MySQL convertit automatiquement la table temporaire en mémoire en une table temporaire InnoDB sur disque. + Instances de base de données de lecteur : la requête se termine par une erreur. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` + Quand `aurora_tmptable_enable_per_table_limit` a pour valeur `ON`, Aurora MySQL a le comportement suivant lorsque la limite `tmp_table_size` est atteinte : + Instances de base de données d’enregistreur : Aurora MySQL convertit automatiquement la table temporaire en mémoire en une table temporaire InnoDB sur disque. + Instances de base de données de lecteur : la requête se termine par une erreur. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` La limite globale des ressources `TempTable` et la limite par table s’appliquent toutes les deux dans ce cas. **Note** Le paramètre `aurora_tmptable_enable_per_table_limit` n’a aucun effet quand [internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) a pour valeur `MEMORY`. Dans ce cas, la taille maximale d’une table temporaire en mémoire est définie par la valeur [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) ou [max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size), la plus petite de ces deux valeurs étant retenue. Les exemples suivants montrent le comportement du paramètre `aurora_tmptable_enable_per_table_limit` pour les instances de base de données d’enregistreur et de lecteur. **Example d’une instance de base de données d’enregistreur avec `aurora_tmptable_enable_per_table_limit` défini sur `OFF`** La table temporaire en mémoire n’est pas convertie en table temporaire InnoDB sur disque. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 0 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (13.99 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example d’une instance de base de données d’enregistreur avec `aurora_tmptable_enable_per_table_limit` défini sur `ON`** La table temporaire en mémoire est convertie en table temporaire InnoDB sur disque. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 0 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; +---------+ | max(n) | +---------+ | 6000000 | +---------+ 1 row in set (4.10 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 1 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example d’une instance de base de données de lecteur avec `aurora_tmptable_enable_per_table_limit` défini sur `OFF`** La requête se termine sans erreur car `tmp_table_size` ne s’applique pas, et la limite globale des ressources `TempTable` n’a pas été atteinte. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (14.05 sec) ``` **Example d’une instance de base de données de lecteur avec `aurora_tmptable_enable_per_table_limit` défini sur `OFF`** Cette requête atteint la limite globale TempTable des ressources lorsqu'elle `aurora_tmptable_enable_per_table_limit` est définie sur OFF. La requête se termine avec une erreur sur les instances de lecteur. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.01 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 120000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_1586_2' is full ``` **Example d’une instance de base de données de lecteur avec `aurora_tmptable_enable_per_table_limit` défini sur `ON`** La requête se termine avec une erreur lorsque la limite `tmp_table_size` est atteinte. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 1 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_8_2' is full ``` ## Atténuation des problèmes de remplissage pour les tables temporaires internes sur les réplicas Aurora Pour éviter les problèmes de limite de taille pour les tables temporaires, définissez les paramètres `temptable_max_ram` et `temptable_max_mmap` sur une valeur combinée, adaptée aux exigences de votre charge de travail. Soyez vigilant lorsque vous définissez la valeur du paramètre `temptable_max_ram`. La définition d'une valeur trop élevée réduit la mémoire disponible sur l'instance de base de données, ce qui peut provoquer un out-of-memory problème. Surveillez la quantité moyenne de mémoire libérable sur l’instance de base de données. Déterminez ensuite une valeur appropriée pour `temptable_max_ram`, de sorte qu’il vous reste une quantité raisonnable de mémoire libre sur l’instance. Pour plus d’informations, consultez [Problèmes liés à la mémoire libérable dans Amazon Aurora](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory). Il est également important de surveiller la taille du stockage local et la consommation d’espace des tables temporaires. Vous pouvez surveiller le stockage temporaire disponible pour une instance de base de données spécifique à l'aide de la CloudWatch métrique `FreeLocalStorage` Amazon, décrite dans[CloudWatch Métriques Amazon pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). **Note** Cette procédure ne fonctionne pas quand le paramètre `aurora_tmptable_enable_per_table_limit` est défini sur `ON`. Pour plus d’informations, consultez [Limitation de la taille des tables temporaires internes en mémoire](#ams3-temptable-behavior-limit). **Example 1** Vous savez que vos tables temporaires atteignent une taille cumulée de 20 Gio. Vous souhaitez définir les tables temporaires en mémoire sur 2 Gio et atteindre une taille maximale de 20 Gio sur disque. Définissez `temptable_max_ram` sur **2,147,483,648** et `temptable_max_mmap` sur **21,474,836,480**. Ces valeurs sont exprimées en octets. Ces valeurs de paramètre garantissent que vos tables temporaires peuvent atteindre un total cumulé de 22 Gio. **Example 2** La taille actuelle de votre instance est 16xlarge ou supérieure. Vous ne connaissez pas la taille totale des tables temporaires dont vous pourriez avoir besoin. Vous souhaitez pouvoir utiliser jusqu’à 4 Gio en mémoire et jusqu’à la taille de stockage maximale disponible sur disque. Définissez `temptable_max_ram` sur **4,294,967,296** et `temptable_max_mmap` sur **1,099,511,627,776**. Ces valeurs sont exprimées en octets. Ici, vous êtes en train de définir `temptable_max_mmap` sur 1 Tio, ce qui est inférieur au stockage local maximal de 1,2 Tio sur une instance de base de données Aurora 16xlarge. Sur une taille d’instance plus petite, ajustez la valeur de `temptable_max_mmap` afin qu’elle ne remplisse pas le stockage local disponible. Par exemple, une instance 2xlarge ne dispose que de 160 Gio de stockage local disponible. Par conséquent, nous vous recommandons de définir la valeur sur 160 Gio au maximum. Pour plus d’informations sur le stockage local disponible pour les tailles d’instance de base de données, consultez [Limites de stockage temporaires pour Aurora MySQLLimites de stockage temporaire](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). ## Optimisation du paramètre temptable\$1max\$1mmap sur les instances de base de données Aurora MySQL Le paramètre `temptable_max_mmap` d’Aurora MySQL contrôle la quantité maximale d’espace disque local qui peut être utilisée par les fichiers mappés en mémoire avant de déborder vers les tables temporaires InnoDB sur disque (sur les instances de base de données d’enregistreur) ou de provoquer une erreur (sur les instances de base de données de lecteur). Une configuration appropriée de ce paramètre d’instance de base de données peut aider à optimiser les performances de vos instances de base de données. **Conditions préalables** 1. Assurez-vous que le schéma de performances est activé. Pour effectuer une vérification, exécutez la commande suivante. ``` SELECT @@performance_schema; ``` La valeur de sortie `1` indique qu’il est activé. 1. Vérifiez que l’instrumentation de mémoire de table temporaire est activée. Pour effectuer une vérification, exécutez la commande suivante. ``` SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%'; ``` La colonne `enabled` indique `YES` pour les entrées d’instrumentation de mémoire de table temporaire pertinentes. **Surveillance de l’utilisation des tables temporaires** Lorsque vous définissez la valeur initiale pour `temptable_max_mmap`, nous vous recommandons de commencer par 80 % de la taille de stockage local pour la classe d’instance de base de données que vous utilisez. Les tables temporaires disposeront ainsi de suffisamment d’espace disque pour fonctionner efficacement, tout en laissant de la place à d’autres utilisations du disque sur l’instance. Pour connaître la taille de stockage local de votre classe d’instance de base de données, consultez [Limites de stockage temporaires pour Aurora MySQLLimites de stockage temporaire](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). Par exemple, si vous utilisez la classe d’instance de base de données db.r5.large, la taille du stockage local est de 32 Gio. Dans ce cas, vous devez initialement définir le paramètre `temptable_max_mmap` pour qu’il corresponde à 80 % de 32 Gio, soit 25,6 Gio. Après avoir défini la valeur `temptable_max_mmap` initiale, exécutez votre charge de travail maximale sur les instances Aurora MySQL. Surveillez l’utilisation actuelle et l’utilisation élevée du disque des tables temporaires à l’aide de la requête SQL suivante : ``` SELECT event_name, current_count, current_alloc, current_avg_alloc, high_count, high_alloc, high_avg_alloc FROM sys.memory_global_by_current_bytes WHERE event_name LIKE 'memory/temptable/%'; ``` Cette requête permet de récupérer les informations suivantes : + `event_name` — Nom de l’événement d’utilisation du disque ou de la mémoire de table temporaire. + `current_count` — Nombre actuel de blocs de disque ou de mémoire de table temporaire alloués. + `current_alloc` — Quantité actuelle de mémoire ou de disque allouée aux tables temporaires. + `current_avg_alloc` — Taille moyenne actuelle des blocs de disque ou de mémoire de table temporaire. + `high_count` — Nombre maximal de blocs disque ou de mémoire de table temporaire alloués. + `high_alloc` — Quantité maximale de mémoire ou de disque allouée aux tables temporaires. + `high_avg_alloc` — Taille moyenne maximale des blocs de disque ou de mémoire de table temporaire. Si vos requêtes échouent avec une erreur de type La table est pleine avec ce paramètre, cela indique que votre charge de travail nécessite plus d’espace disque pour les opérations des tables temporaires. Dans ce cas, envisagez d’augmenter la taille de votre instance de base de données pour qu’elle dispose d’un espace de stockage local plus important. **Configuration de la valeur `temptable_max_mmap` optimale** Utilisez la procédure suivante pour surveiller et définir la taille appropriée pour le paramètre `temptable_max_mmap`. 1. Passez en revue le résultat de la requête précédente et identifiez le pic d’utilisation du disque de table temporaire, comme indiqué dans la colonne `high_alloc`. 1. En fonction du pic d’utilisation du disque de table temporaire, ajustez le paramètre `temptable_max_mmap` dans le groupe de paramètres de base de données de vos instances de base de données Aurora MySQL. Définissez cette valeur pour qu’elle soit légèrement supérieure au pic d’utilisation du disque de table temporaire afin de tenir compte de la croissance future. 1. Appliquez les modifications du groupe de paramètres à vos instances de base de données. 1. Surveillez à nouveau l’utilisation du disque de table temporaire pendant votre charge de travail maximale pour vous assurer que la nouvelle valeur `temptable_max_mmap` est appropriée. 1. Répétez les étapes précédentes autant de fois que nécessaire pour optimiser le paramètre `temptable_max_mmap`. ## Tables temporaires (explicites) créées par l’utilisateur sur les instances de base de données de lecteur Vous pouvez créer des tables temporaires explicites en utilisant le mot-clé `TEMPORARY` dans votre instruction `CREATE TABLE`. Les tables temporaires explicites sont prises en charge sur l’instance de base de données d’enregistreur dans un cluster de bases de données Aurora. Vous pouvez également utiliser des tables temporaires explicites sur les instances de base de données de lecteur, mais les tables ne peuvent pas imposer l’utilisation du moteur de stockage InnoDB. Pour éviter les erreurs lors de la création de tables temporaires explicites sur les instances de base de données de lecture Aurora MySQL, assurez-vous d’exécuter toutes les instructions `CREATE TEMPORARY TABLE` de l’une ou l’autre des manières suivantes, ou des deux : + Ne spécifiez pas la clause `ENGINE=InnoDB`. + Ne définissez pas le mode SQL sur `NO_ENGINE_SUBSTITUTION`. ## Erreurs de création d’une table temporaire et atténuation L’erreur que vous recevez est différente selon que vous utilisez ou non une instruction `CREATE TEMPORARY TABLE` simple ou la variante `CREATE TEMPORARY TABLE AS SELECT`. Les exemples suivants montrent les différents types d’erreurs. Ce comportement de table temporaire s’applique uniquement aux instances en lecture seule. Ce premier exemple confirme que c’est le type d’instance à laquelle la session est connectée. ``` mysql> select @@innodb_read_only; +--------------------+ | @@innodb_read_only | +--------------------+ | 1 | +--------------------+ ``` Les instructions `CREATE TEMPORARY TABLE` simples échouent lorsque le mode SQL `NO_ENGINE_SUBSTITUTION` est activé. Lorsque `NO_ENGINE_SUBSTITUTION` est désactivé (par défaut), la substitution du moteur approprié est effectuée et la création de la table temporaire aboutit. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB; mysql> SHOW CREATE TABLE tt4\G *************************** 1. row *************************** Table: tt4 Create Table: CREATE TEMPORARY TABLE `tt4` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ``` Les instructions `CREATE TEMPORARY TABLE AS SELECT` échouent quand le mode SQL `NO_ENGINE_SUBSTITUTION` est activé. Lorsque `NO_ENGINE_SUBSTITUTION` est désactivé (par défaut), la substitution du moteur approprié est effectuée et la création de la table temporaire aboutit. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> show create table tt3; +-------+----------------------------------------------------------+ | Table | Create Table | +-------+----------------------------------------------------------+ | tt3 | CREATE TEMPORARY TABLE `tt3` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci | +-------+----------------------------------------------------------+ 1 row in set (0.00 sec) ``` Pour plus d'informations sur les aspects liés au stockage et les implications en termes de performances des tables temporaires dans Aurora MySQL version 3, consultez le billet de blog [Utiliser le moteur de TempTable stockage sur Amazon RDS for MySQL et Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).