# Novo comportamento de tabela temporária no Aurora MySQL versão 3 O Aurora MySQL versão 3 processa as tabelas temporárias internas de forma diferente das versões anteriores do Aurora MySQL. Esse novo comportamento é herdado do MySQL 8.0 Community Edition. Existem dois tipos de tabelas temporárias que podem ser criadas com o Aurora MySQL versão 3: + Tabelas temporárias internas (ou *implícitas*): criadas pelo mecanismo do Aurora MySQL para lidar com operações, como agregação de classificação, tabelas derivadas ou expressões de tabela comuns (CTEs). + Tabelas temporárias criadas pelo usuário (ou *explícitas*): criadas pelo mecanismo do Aurora MySQL quando você usa a instrução `CREATE TEMPORARY TABLE`. Há considerações adicionais sobre tabelas temporárias internas e criadas pelo usuário em instâncias de banco de dados do leitor do Aurora. Abordamos essas alterações nas seções a seguir. **Topics** + [Mecanismo de armazenamento para tabelas temporárias internas (implícitas)](#ams3-temptable-behavior-engine) + [Limitar o tamanho de tabelas temporárias internas na memória](#ams3-temptable-behavior-limit) + [Mitigar problemas de volume em tabelas temporárias internas em réplicas do Aurora](#ams3-temptable-behavior-mitigate) + [Otimizar o parâmetro temptable\_max\_mmap nas instâncias de banco de dados do Aurora MySQL](#ams-optimize-temptable_max_mmap) + [Tabelas temporárias criadas pelo usuário (explícitas) em instâncias de banco de dados de leitor](#ams3-temptable-behavior.user) + [Mitigação e erros de criação de tabelas temporárias](#ams3-temptable-behavior.errors) ## Mecanismo de armazenamento para tabelas temporárias internas (implícitas) Ao gerar conjuntos de resultados intermediários, o Aurora MySQL inicialmente tenta gravar em tabelas temporárias na memória. Esse procedimento pode não ser bem-sucedido devido a tipos de dados incompatíveis ou limites configurados. Se esse for o caso, a tabela temporária será convertida em uma tabela temporária no disco, em vez de mantida na memória. Mais informações sobre isso podem ser encontradas em [Uso de tabela temporária interna no MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) na documentação do MySQL. No Aurora MySQL versão 3, a maneira como as tabelas temporárias internas funcionam é diferente das versões anteriores do Aurora MySQL. Em vez de escolher entre os mecanismos de armazenamento InnoDB e MyISAM para essas tabelas temporárias, agora você escolhe entre os mecanismos de armazenamento `TempTable` e `MEMORY`. Com o mecanismo de armazenamento `TempTable`, é possível fazer uma escolha adicional de como lidar com determinados dados. Os dados afetados transbordam o pool de memória que contém todas as tabelas temporárias internas da instância de banco de dados. Essas opções podem influenciar a performance de consultas que geram altos volumes de dados temporários, por exemplo, ao realizar agregações como `GROUP BY` em tabelas grandes. **dica** Se a sua workload incluir consultas que geram tabelas temporárias internas, confirme a performance da sua aplicação com essa alteração executando benchmarks e monitorando métricas de performance. Em alguns casos, a quantidade de dados temporários se encaixa no grupo de memória `TempTable` ou apenas transborda o grupo de memória em uma pequena quantidade. Nesses casos, convém utilizar a configuração `TempTable` para tabelas temporárias internas e arquivos mapeados para a memória a fim de conter quaisquer dados de estouro. Essa é a configuração padrão. O mecanismo de armazenamento `TempTable` é o padrão. `TempTable` usa um grupo de memória comum para todas as tabelas temporárias que usam esse mecanismo, em vez de um limite máximo de memória por tabela. O tamanho desse grupo de memória é especificado pelo parâmetro [temptable\_max\_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram). O padrão é 1 GiB em instâncias de banco de dados com 16 GiB ou mais de memória e 16 MB em instâncias de banco de dados com menos de 16 GiB de memória. O tamanho do grupo de memória influencia o consumo de memória em nível de sessão. Em alguns casos, quando você usa o mecanismo de armazenamento `TempTable`, os dados temporários podem exceder o tamanho do grupo de memória. Nesse caso, o Aurora MySQL armazena os dados de transbordamento usando um mecanismo secundário. É possível definir o parâmetro [temptable\_max\_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) para escolher se os dados transbordam para arquivos temporários mapeados pela memória ou para tabelas temporárias internas do InnoDB no disco. Os diferentes formatos de dados e critérios de transbordamento desses mecanismos de transbordamento podem afetar a performance das consultas. Isso ocorre devido à sua influência sobre a quantidade de dados gravados no disco e a demanda na taxa de transferência de armazenamento em disco. O Aurora MySQL versão 3 armazena os dados de transbordamento da seguinte forma: + Na instância de banco de dados de gravação, os dados que transbordam para tabelas temporárias internas do InnoDB ou para arquivos temporários mapeados em memória residem no armazenamento local na instância. + Em instâncias de banco de dados de leitor, os dados de transbordamento sempre residem em arquivos temporários mapeados para a memória no armazenamento local. Instâncias somente leitura não podem armazenar dados no volume do cluster do Aurora. Os parâmetros de configuração relacionados a tabelas temporárias internas são aplicáveis de maneira diferente às instâncias de gravador e de leitor no seu cluster: + Em instâncias do leitor, o Aurora MySQL sempre utiliza o mecanismo de armazenamento `TempTable`. + O tamanho de `temptable_max_mmap` é de 1 GiB por padrão, tanto para instâncias do gravador quanto do leitor, independentemente do tamanho da memória da instância de banco de dados. Você pode ajustar esse valor em instâncias do gravador e do leitor. + A configuração de `temptable_max_mmap` para `0` desativa o uso de arquivos temporários mapeados na memória em instâncias do gravador. + Você não pode definir `temptable_max_mmap` como `0` em instâncias do leitor. **nota** Não recomendamos utilizar o parâmetro [temptable\_use\_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap). Ele foi descontinuado, e há previsões de que o suporte será removido em uma versão futura do MySQL. ## Limitar o tamanho de tabelas temporárias internas na memória Conforme abordado em [Mecanismo de armazenamento para tabelas temporárias internas (implícitas)](#ams3-temptable-behavior-engine), é possível controlar recursos de tabelas temporárias globalmente usando as configurações [temptable\_max\_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) e [temptable\_max\_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap). Você também pode limitar o tamanho de qualquer tabela temporária interna individual na memória usando o parâmetro de banco de dados [tmp\_table\_size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size). Esse limite tem como objetivo evitar que consultas individuais consumam uma quantidade excessiva de recursos globais de tabelas temporárias, o que pode afetar a performance de consultas simultâneas que exigem esses recursos. O parâmetro `tmp_table_size` define o tamanho máximo das tabelas temporárias criadas pelo mecanismo de armazenamento `MEMORY` no Aurora MySQL versão 3. No Aurora MySQL versão 3.04 e posterior, `tmp_table_size` também define o tamanho máximo das tabelas temporárias criadas pelo mecanismo de armazenamento `TempTable` quando o parâmetro de banco de dados `aurora_tmptable_enable_per_table_limit` é definido como `ON`. Esse comportamento, que está desabilitado (`OFF`) por padrão, é o mesmo que no Aurora MySQL versão 3.03 e versões anteriores. + Quando `aurora_tmptable_enable_per_table_limit` está `OFF`, `tmp_table_size` não é considerado para tabelas temporárias internas na memória criadas pelo mecanismo de armazenamento `TempTable`. No entanto, o limite dos recursos `TempTable` globais ainda se aplica. O Aurora MySQL tem o seguinte comportamento quando o limite de recursos `TempTable` globais é atingido: + Instâncias de banco de dados de gravador: o Aurora MySQL converte automaticamente a tabela temporária na memória em uma tabela temporária em disco do InnoDB. + Instâncias de banco de dados de leitor: a consulta termina com um erro. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sql{{xx_xxx}}' is full ``` + Quando `aurora_tmptable_enable_per_table_limit` está `ON` e o limite de `tmp_table_size` é atingido, o Aurora MySQL tem o seguinte comportamento: + Instâncias de banco de dados de gravador: o Aurora MySQL converte automaticamente a tabela temporária na memória em uma tabela temporária em disco do InnoDB. + Instâncias de banco de dados de leitor: a consulta termina com um erro. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sql{{xx_xxx}}' is full ``` Tanto o limite de recursos `TempTable` globais quanto o limite por tabela se aplicam nesse caso. **nota** O parâmetro `aurora_tmptable_enable_per_table_limit` não tem efeito quando [internal\_tmp\_mem\_storage\_engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) está definido como `MEMORY`. Nesse caso, o tamanho máximo de uma tabela temporária na memória é definido pelo valor [tmp\_table\_size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) ou [max\_heap\_table\_size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size), o que for menor. Os exemplos a seguir mostram o comportamento do parâmetro `aurora_tmptable_enable_per_table_limit` para instâncias de banco de dados de gravador e leitor. **Example da instância de banco de dados de gravador com `aurora_tmptable_enable_per_table_limit` definido como `OFF`.** A tabela temporária na memória não é convertida em uma tabela temporária em disco do InnoDB. ``` 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 da instância de banco de dados de gravador com `aurora_tmptable_enable_per_table_limit` definido como `ON`.** A tabela temporária na memória não é convertida em uma tabela temporária em disco do InnoDB. ``` 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 da instância de banco de dados de leitor com `aurora_tmptable_enable_per_table_limit` definido como `OFF`.** A consulta termina sem um erro porque `tmp_table_size` não se aplica e o limite de recursos `TempTable` globais não foi atingido. ``` 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 da instância de banco de dados de leitor com `aurora_tmptable_enable_per_table_limit` definido como `OFF`.** Essa consulta atinge o limite global de recursos TempTable com `aurora_tmptable_enable_per_table_limit` definido como DESATIVADO. A consulta termina com um erro nas instâncias de leitor. ``` 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 da instância de banco de dados de leitor com `aurora_tmptable_enable_per_table_limit` definido como `ON`.** A consulta termina com um erro quando o limite `tmp_table_size` é atingido. ``` 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 ``` ## Mitigar problemas de volume em tabelas temporárias internas em réplicas do Aurora Para evitar problemas de limitação de tamanho de tabelas temporárias, defina os parâmetros `temptable_max_ram` e `temptable_max_mmap` para um valor combinado que pode atender aos requisitos de sua workload. Tenha cuidado ao definir o valor do parâmetro `temptable_max_ram`. Definir o valor muito alto reduz a memória disponível na instância do banco de dados, o que pode causar uma condição de falta de memória. Monitore a memória média livre na instância de banco de dados. Depois, determine um valor apropriado para `temptable_max_ram` para que você ainda tenha uma quantidade razoável de memória livre na instância. Para obter mais informações, consulte [Problemas de memória liberável no Amazon Aurora](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory). Também é importante monitorar o tamanho do armazenamento local e o consumo de espaço em tabelas temporárias. É possível monitorar o armazenamento temporário disponível para uma instância de banco de dados específica com a métrica `FreeLocalStorage` do Amazon CloudWatch, descrita em [Métricas do Amazon CloudWatch para o Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). **nota** Esse procedimento não funciona quando o parâmetro `aurora_tmptable_enable_per_table_limit` está definido como `ON`. Para obter mais informações, consulte [Limitar o tamanho de tabelas temporárias internas na memória](#ams3-temptable-behavior-limit). **Example 1** Você sabe que suas tabelas temporárias aumentam até um tamanho cumulativo de 20 GiB. Você deseja definir tabelas temporárias na memória como 2 GiB e aumentar para um máximo de 20 GiB em disco. Defina `temptable_max_ram` como **2,147,483,648** e `temptable_max_mmap` como **21,474,836,480**. Esses valores estão em bytes. Essas configurações de parâmetros garantem que suas tabelas temporárias possam aumentar até um total cumulativo de 22 GiB. **Example 2** O tamanho da instância atual é 16xlarge ou maior. Você não sabe o tamanho total das tabelas temporárias que pode precisar. Você deseja ter a capacidade de usar até 4 GiB na memória e até o tamanho máximo de armazenamento disponível no disco. Defina `temptable_max_ram` como **4,294,967,296** e `temptable_max_mmap` como **1,099,511,627,776**. Esses valores estão em bytes. Aqui você está definindo `temptable_max_mmap` como 1 TiB, que é inferior ao armazenamento local máximo de 1,2 TiB em uma instância de banco de dados 16xlarge do Aurora. Em um tamanho de instância menor, ajuste o valor de `temptable_max_mmap` para que ele não preencha o armazenamento local disponível. Por exemplo, uma instância 2xlarge tem apenas 160 GiB de armazenamento local disponível. Por isso, recomendamos definir o valor como menos de 160 GiB. Para obter mais informações sobre o armazenamento local disponível para tamanhos de instância de banco de dados, consulte [Limites de armazenamento temporário para o Aurora MySQLLimites de armazenamento temporário](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). ## Otimizar o parâmetro temptable\_max\_mmap nas instâncias de banco de dados do Aurora MySQL O parâmetro `temptable_max_mmap` no Aurora MySQL controla a quantidade máxima de espaço em disco local que pode ser usada por arquivos mapeados na memória antes de transbordar para as tabelas temporárias do InnoDB em disco (em instâncias de banco de dados de gravador) ou causar um erro (em instâncias de banco de dados de leitor). Definir esse parâmetro de instância de banco de dados corretamente pode ajudar a otimizar o desempenho das instâncias de banco de dados. **Pré-requisitos** 1. O Performance Schema deve estar habilitado. Você pode verificar isso executando o seguinte comando SQL: ``` SELECT @@performance_schema; ``` Um valor de saída de `1` indica que ele está habilitado. 1. Confirme se a instrumentação de memória de tabela temporária está habilitada. Você pode verificar isso executando o seguinte comando SQL: ``` SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%'; ``` A coluna `enabled` mostra `YES` para as entradas relevantes de instrumentação de memória de tabela temporária. **Monitorar o uso de tabelas temporárias** Ao definir o valor inicial para `temptable_max_mmap`, recomendamos que você comece com 80% do tamanho do armazenamento local para a classe de instância de banco de dados que está usando. Isso garante que as tabelas temporárias tenham espaço em disco suficiente para operar com eficiência, ao mesmo tempo em que deixa espaço para outros usos do disco na instância. Para encontrar o tamanho do armazenamento local para sua classe de instância de banco de dados, consulte [Limites de armazenamento temporário para o Aurora MySQLLimites de armazenamento temporário](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). Por exemplo, se você estiver usando a classe de instância de banco de dados db.r5.large, o tamanho do armazenamento local é de 32 GiB. Nesse caso, você definiria inicialmente o parâmetro `temptable_max_mmap` para 80% de 32 GiB, que é 25,6 GiB. Depois de definir o valor inicial de `temptable_max_mmap`, execute a workload máxima nas instâncias do Aurora MySQL. Monitore o uso atual e máximo do disco de tabela temporária usando a seguinte consulta SQL: ``` 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/%'; ``` Essa consulta recupera as seguintes informações: + `event_name`: o nome do evento de uso de memória ou disco de tabelas temporárias. + `current_count`: o número atual de blocos de memória ou disco alocados de tabelas temporárias. + `current_alloc`: a quantidade atual de memória ou disco alocada para tabelas temporárias. + `current_avg_alloc`: o tamanho médio atual dos blocos de memória ou disco de tabelas temporárias. + `high_count`: o maior número de blocos de memória ou disco alocados de tabelas temporárias. + `high_alloc`: a maior quantidade de memória ou disco alocada para tabelas temporárias. + `high_avg_alloc`: o maior tamanho médio dos blocos de memória ou disco de tabelas temporárias. Se as consultas falharem com um erro Table is full usando essa configuração, isso indica que a workload requer mais espaço em disco para operações de tabelas temporárias. Nesse caso, considere aumentar o tamanho da instância de banco de dados para uma com mais espaço de armazenamento local. **Definir o valor ideal de `temptable_max_mmap`** Use o procedimento a seguir para monitorar e definir o tamanho correto para o parâmetro `temptable_max_mmap`. 1. Analise a saída da consulta anterior e identifique o pico de uso de disco para tabelas temporárias, conforme indicado pela coluna `high_alloc`. 1. Com base no pico de uso de disco de tabelas temporárias, ajuste o parâmetro `temptable_max_mmap` no grupo de parâmetros do banco de dados para as instâncias de banco de dados do Aurora MySQL. Defina o valor para ser um pouco maior do que o pico de uso de disco de tabelas temporárias para acomodar o crescimento futuro. 1. Aplique as alterações do grupo de parâmetros às instâncias de banco de dados. 1. Monitore o uso de disco de tabelas temporárias novamente durante o pico de workload para garantir que o novo valor de `temptable_max_mmap` seja apropriado. 1. Repita as etapas anteriores conforme necessário para ajustar o parâmetro `temptable_max_mmap`. ## Tabelas temporárias criadas pelo usuário (explícitas) em instâncias de banco de dados de leitor Você pode criar explicitamente tabelas temporárias usando uma palavra-chave `TEMPORARY` em sua instrução `CREATE TABLE`. As tabelas temporárias explícitas são compatíveis com a instância de banco de dados do gravador em um cluster de banco de dados do Aurora. Você também pode usar tabelas temporárias explícitas em instâncias de banco de dados do leitor, mas as tabelas não podem impor o uso do mecanismo de armazenamento InnoDB. Para evitar erros ao criar tabelas temporárias explícitas em instâncias de banco de dados do leitor do Aurora MySQL, execute todas as instruções `CREATE TEMPORARY TABLE` em instâncias de banco de dados do leitor de uma destas maneiras: + Não especifique a cláusula `ENGINE=InnoDB`. + Não defina o modo SQL como `NO_ENGINE_SUBSTITUTION`. ## Mitigação e erros de criação de tabelas temporárias O erro retornado é diferente dependendo de você utilizar uma instrução `CREATE TEMPORARY TABLE` simples ou a variação `CREATE TEMPORARY TABLE AS SELECT`. Os exemplos a seguir mostram os diferentes tipos de erros. Esse comportamento de tabela temporária apenas se aplica a instâncias somente leitura. Esse primeiro exemplo confirma que este é o tipo de instância à qual a sessão está conectada. ``` mysql> select @@innodb_read_only; +--------------------+ | @@innodb_read_only | +--------------------+ | 1 | +--------------------+ ``` Para instruções `CREATE TEMPORARY TABLE` simples, a instrução falha quando o modo SQL `NO_ENGINE_SUBSTITUTION` está habilitado. Quando `NO_ENGINE_SUBSTITUTION` está desativado (padrão), a substituição do mecanismo apropriado é feita e a criação temporária da tabela é bem-sucedida. ``` 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 ``` Para instruções `CREATE TEMPORARY TABLE AS SELECT`, a instrução falha quando o modo SQL `NO_ENGINE_SUBSTITUTION` está ativado. Quando `NO_ENGINE_SUBSTITUTION` está desativado (padrão), a substituição do mecanismo apropriado é feita e a criação temporária da tabela é bem-sucedida. ``` 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) ``` Para obter mais informações sobre os aspectos de armazenamento e as implicações de performance de tabelas temporárias no Aurora MySQL versão 3, consulte a postagem do blog [Usar o mecanismo de armazenamento TempTable no Amazon RDS para MySQL e Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).