Neues temporäres Tabellenverhalten in Aurora-MySQL-Version 3

Aurora MySQL Version 3 behandelt temporäre Tabellen anders als frühere Aurora-MySQL-Versionen. Dieses neue Verhalten wird von der Community Edition von MySQL 8.0 geerbt. Es gibt zwei Arten von temporären Tabellen, die mit Aurora MySQL Version 3 erstellt werden können:

• Interne (oder implizite) temporäre Tabellen – werden von der Aurora-MySQL-Engine erstellt, um Vorgänge wie Sortieraggregation, abgeleitete Tabellen oder allgemeine Tabellenausdrücke (CTEs) zu behandeln.

• Vom Benutzer erstellte (oder explizite) temporäre Tabellen – werden von der Aurora-MySQL-Engine erstellt, wenn Sie die Anweisung CREATE TEMPORARY TABLE verwenden.

Es gibt zusätzliche Überlegungen sowohl für interne als auch für vom Benutzer erstellte temporäre Tabellen auf Aurora-Reader-DB-Instances. Diese werden in den folgenden Abschnitten erläutert.

Speicher-Engine für interne (implizite) temporäre Tabellen

Beim Generieren von Zwischenergebnismengen versucht Aurora MySQL zunächst, in temporäre Tabellen im Arbeitsspeicher zu schreiben. Dies ist aufgrund inkompatibler Datentypen oder konfigurierter Grenzwerte möglicherweise nicht erfolgreich. In diesem Fall wird die temporäre Tabelle in eine temporäre Tabelle auf dem Datenträger konvertiert, anstatt im Arbeitsspeicher abgelegt zu werden. Weitere Informationen hierzu finden Sie unter Verwendung interner temporärer Tabellen in MySQL in der MySQL-Dokumentation.

In Aurora-MySQL-Version 3 unterscheidet sich die Funktionsweise interner temporärer Tabellen von früheren Aurora-MySQL-Versionen. Anstatt sich für solche temporären Tabellen zwischen den InnoDB- und MyISAM-Speicher-Engines zu entscheiden, wählen Sie jetzt zwischen denTempTableund InnoDB Storage-Engines.

Mit derTempTableSpeicher-Engine können Sie eine zusätzliche Auswahl für den Umgang mit bestimmten Daten treffen. Die betroffenen Daten überlaufen den Speicherpool, der alle internen temporären Tabellen für die DB-Instance enthält.

Diese Optionen können die Leistung von Abfragen beeinflussen, die hohe Mengen an temporären Daten generieren, z. B. während der Durchführung von Aggregationen wie GROUP BY auf großen Tabellen.

Tipp

Wenn Ihre Workload Abfragen enthält, die interne temporäre Tabellen generieren, bestätigen Sie, wie Ihre Anwendung mit dieser Änderung funktioniert, indem Sie Benchmarks ausführen und leistungsbezogene Metriken überwachen.

In einigen Fällen passt die Menge an temporären Daten inTempTableSpeicherpool oder überläuft den Speicherpool nur um einen kleinen Betrag. In diesen Fällen empfehlen wir die TempTable-Einstellung für interne temporäre Tabellen und speicherzugeordnete Dateien, um Überlaufdaten zu speichern. Dies ist die Standardeinstellung.

Die TempTable-Speicher-Engine ist die Standardeinstellung. TempTable verwendet einen gemeinsamen Speicherpool für alle temporären Tabellen, die diese Engine verwenden, anstelle eines maximalen Speicherlimits pro Tabelle. Die Größe dieses Speicherpools wird durch den Parameter temptable_max_ram angegeben. Der Wert dieses Parameters beträgt standardmäßig 1 GiB bei DB-Instances mit 16 oder mehr GiB Arbeitsspeicher und 16 MB bei DB-Instances mit weniger als 16 GB Arbeitsspeicher. Die Größe des Speicherpools beeinflusst den Speicherverbrauch auf Sitzungsebene.

Bei Verwendung der Speicher-Engine TempTable kann es vorkommen, dass die temporären Daten die Größe des Speicherpools überschreiten. In diesem Fall speichert Aurora MySQL die Überlaufdaten mithilfe eines sekundären Mechanismus.

Sie können den Parameter temptable_max_mmap festlegen, um anzugeben, ob die Daten zu temporären Dateien im Arbeitsspeicher oder zu internen temporären Tabellen von InnoDB auf der Festplatte überlaufen werden. Die verschiedenen Datenformate und Überlaufkriterien dieser Überlaufmechanismen können sich auf die Abfrageleistung auswirken. Sie tun dies, indem sie die Menge der auf die Festplatte geschriebenen Daten und die Nachfrage nach Festplattenspeicherdurchsatz beeinflussen.

Aurora MySQL speichert die Überlaufdaten unterschiedlich, abhängig von der Wahl des Datenüberlaufziels und ob die Abfrage auf einer Writer- oder Reader-DB-Instance ausgeführt wird:

• In der Writer-Instanz werden Daten, die zu internen temporären Tabellen von InnoDB überlaufen, im Aurora-Cluster-Volume gespeichert.

• In der Writer-Instanz befinden sich Daten, die zu speicherzugeordneten temporären Dateien überlaufen, auf lokalem Speicher auf der Aurora MySQL-Version 3-Instanz.

• Bei Reader-Instanzen befinden sich Überlaufdaten immer auf speicherzugeordneten temporären Dateien auf lokalem Speicher. Dies liegt daran, dass schreibgeschützte Instances keine Daten auf dem Aurora-Cluster-Volume speichern können.

Die Konfigurationsparameter für interne temporäre Tabellen gelten unterschiedlich für die Writer- und Reader-Instanzes in Ihrem Cluster.

• Für Reader-Instances verwendet Aurora MySQL immer die Speicher–Engine TempTable.

• Die Größe für temptable_max_mmap beträgt für Writer- und Reader-Instances unabhängig von der Speichergröße der DB-Instance standardmäßig 1 GB. Sie können diesen Wert sowohl für Writer- als auch für Reader-Instances anpassen.

• Die Einstellung von temptable_max_mmap auf 0 deaktiviert die Verwendung von temporären Dateien mit Speicherzuordnung auf Writer-Instances.

• Sie können 0 auf Reader-Instances nicht auf temptable_max_mmap setzen.

Anmerkung

Es wird nicht empfohlen, den temptable_use_mmap-Parameter zu verwenden. Dieser ist veraltet, und es wird erwartet, dass die Unterstützung dafür in einer künftigen MySQL-Version entfernt wird.

Begrenzung der Größe interner temporärer Tabellen im Arbeitsspeicher

Wie in Speicher-Engine für interne (implizite) temporäre Tabellen erwähnt, können Sie temporäre Tabellenressourcen global steuern, indem Sie die Einstellungen temptable_max_ram und temptable_max_mmap verwenden.

Sie können die Größe jeder einzelnen internen temporären Tabelle im Arbeitsspeicher auch einschränken, indem Sie den DB-Parameter tmp_table_size verwendenParameter. Dieses Limit soll verhindern, dass einzelne Abfragen übermäßig viele globale temporäre Tabellenressourcen verbrauchen, was sich auf die Leistung gleichzeitiger Abfragen auswirken kann, die diese Ressourcen benötigen.

Der Parameter tmp_table_size definiert die maximale Größe temporärer Tabellen, die von der MEMORY-Speicher-Engine in Aurora-MySQL-Version 3 erstellt werden.

In Aurora-MySQL-Version 3.04 und höher definiert der Parameter tmp_table_size auch die maximale Größe temporärer Tabellen, die von der TempTable-Speicher-Engine erstellt werden, wenn der DB-Parameter aurora_tmptable_enable_per_table_limit auf ON festgelegt ist. Dieses Verhalten ist standardmäßig deaktiviert (OFF). Dies entspricht dem Verhalten von Aurora-MySQL-Version 3.03 und niedrigeren Versionen.

• Wenn aurora_tmptable_enable_per_table_limit OFF ist ,wird tmp_table_size nicht für interne temporäre Tabellen im Arbeitsspeicher berücksichtigt, die von derTempTable-Speicher-Engine erstellt wurden.

  Das globale TempTable-Ressourcenlimit gilt jedoch weiterhin. Aurora MySQL verhält sich wie folgt, wenn das globale TempTable-Ressourcenlimit erreicht wird:

  • Writer-DB-Instances – Aurora MySQL konvertiert die temporäre Tabelle im Arbeitsspeicher automatisch in eine temporäre InnoDB-Tabelle auf der Festplatte.

  • Reader-DB-Instances – Die Abfrage endet mit einem Fehler.

    ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full

• Wenn aurora_tmptable_enable_per_table_limit ON ist, verhält sich Aurora MySQL wie folgt, wenn das tmp_table_size-Limit erreicht wird:

  • Writer-DB-Instances – Aurora MySQL konvertiert die temporäre Tabelle im Arbeitsspeicher automatisch in eine temporäre InnoDB-Tabelle auf der Festplatte.

  • Reader-DB-Instances – Die Abfrage endet mit einem Fehler.

    ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full

    In diesem Fall gelten sowohl das globale TempTable-Ressourcenlimit als auch das Limit pro Tabelle.

Anmerkung

Der aurora_tmptable_enable_per_table_limit-Parameter hat keine Auswirkungen, wenn interne_tmp_mem_storage_engine auf MEMORY eingestellt ist. In diesem Fall wird die maximale Größe einer temporären Tabelle im Arbeitsspeicher durch den Wert tmp_table_size oder max_heap_table_size definiert, je nachdem, welcher Wert kleiner ist.

Die folgenden Beispiele zeigen das Verhalten des aurora_tmptable_enable_per_table_limit-Parameters für Writer- und Reader-DB-Instances.

Beispiel einer Writer-DB-Instance mit der Einstellung aurora_tmptable_enable_per_table_limit auf OFF

Die temporäre Tabelle im Arbeitsspeicher wird nicht in eine temporäre InnoDB-Tabelle auf dem Datenträger konvertiert.

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)

Beispiel einer Writer-DB-Instance mit der Einstellung aurora_tmptable_enable_per_table_limit auf ON

Die temporäre Tabelle im Arbeitsspeicher wird in eine temporäre InnoDB-Tabelle auf dem Datenträger konvertiert.

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)

Beispiel einer Reader-DB-Instance mit der Einstellung aurora_tmptable_enable_per_table_limit auf OFF

Die Abfrage wird ohne Fehler beendet, weil tmp_table_size nicht zutrifft, und das globale TempTable-Ressourcenlimit wurde nicht erreicht.

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)

Beispiel einer Reader-DB-Instance mit der Einstellung aurora_tmptable_enable_per_table_limit auf OFF

Diese Abfrage erreicht das globale TempTable-Ressourcenlimit, wobei aurora_tmptable_enable_per_table_limit auf OFF eingestellt ist. Die Abfrage endet mit einem Fehler auf den Reader-Instances.

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

Beispiel einer Reader-DB-Instance mit der Einstellung aurora_tmptable_enable_per_table_limit auf ON

Die Abfrage endet mit einem Fehler, wenn das tmp_table_size-Limit erreicht wird.

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

Abschwächung von Füllungsgradproblemen bei internen temporären Tabellen auf Aurora Replicas

Sie können Probleme mit der Größenbeschränkung für temporäre Tabellen vermeiden, indem Sie die Parameter temptable_max_ram und temptable_max_mmap auf einen kombinierten Wert festlegen, der die Anforderungen Ihrer Workloads erfüllen kann.

Seien Sie vorsichtig, wenn Sie den Wert des Parameters temptable_max_ram festlegen. Wenn Sie den Wert zu hoch einstellen, wird der verfügbare Arbeitsspeicher auf der Datenbank-Instance reduziert, was zu einer Out-of-Memory-Bedingung führen kann. Überwachen Sie den durchschnittlichen möglichen freien Arbeitsspeicher der DB-Instance. Ermitteln Sie dann einen geeigneten Wert für temptable_max_ram, damit Sie immer noch angemessenen freien Speicherplatz auf der Instance zur Verfügung haben. Weitere Informationen finden Sie unter Probleme mit freisetzbarem Speicher in Amazon Aurora.

Es ist auch wichtig, die Größe des lokalen Speichers und die Speicherplatzbelegung durch die temporäre Tabelle zu überwachen. Weitere Informationen zur Überwachung des lokalen Arbeitsspeichers auf einer Instance finden Sie im AWS-Wissenscenter-Artikel Was ist im Aurora-MySQL-kompatiblen lokalen Speicher gespeichert und wie kann ich lokale Speicherprobleme beheben?.

Anmerkung

Dieses Verfahren funktioniert nicht, wenn der aurora_tmptable_enable_per_table_limit-Parameter auf ON festgelegt ist. Weitere Informationen finden Sie unter Begrenzung der Größe interner temporärer Tabellen im Arbeitsspeicher.

Beispiel 1

Sie wissen, dass Ihre temporären Tabellen auf eine kumulative Größe von 20 GiB anwachsen. Sie möchten temporäre In-Memory-Tabellen auf 2 GiB festlegen und auf maximal 20 GiB auf der Festplatte anwachsen lassen.

Setzen Sie temptable_max_ram auf 2,147,483,648 und temptable_max_mmap auf 21,474,836,480. Diese Werte werden in Byte angegeben.

Diese Parametereinstellungen stellen sicher, dass Ihre temporären Tabellen auf eine kumulative Summe von 22 GiB anwachsen können.

Beispiel 2

Ihre aktuelle Instance-Größe ist 16xlarge oder größer. Sie kennen nicht die Gesamtgröße der temporären Tabellen, die Sie möglicherweise benötigen. Sie möchten bis zu 4 GiB im Arbeitsspeicher und den maximal verfügbaren Speicher auf der Festplatte nutzen können.

Setzen Sie temptable_max_ram auf 4,294,967,296 und temptable_max_mmap auf 1,099,511,627,776. Diese Werte werden in Byte angegeben.

Hier legen Sie temptable_max_mmap auf 1 TiB fest, was weniger als der maximale lokale Speicher von 1,2 TiB auf einer Aurora-DB-Instance der Größe 16xlarge ist.

Passen Sie bei einer kleineren Instance-Größe den Wert temptable_max_mmap an, damit der verfügbare lokale Arbeitsspeicher nicht vollständig belegt wird. Bei einer 2xlarge-Instance stehen für den lokalen Speicher beispielsweise nur 160 GiB zur Verfügung. Daher empfehlen wir, den Wert auf weniger als 160 GiB einzustellen. Weitere Informationen über den verfügbaren lokalen Speicher für DB-Instance-Größen finden Sie unter Temporäre Speicherlimits für Aurora MySQL.

Vom Benutzer erstellte (explizite) temporäre Tabellen auf Reader-DB-Instances

Sie können explizite temporäre Tabellen erstellen, indem Sie das Schlüsselwort TEMPORARY in Ihrer Anweisung CREATE TABLE verwenden. Explizite temporäre Tabellen werden auf der Writer-DB-Instance in einem Aurora-DB-Cluster unterstützt. Sie können auch explizite temporäre Tabellen für Reader DB-Instances verwenden. Die Tabellen können jedoch die Verwendung der InnoDB-Speicher-Engine nicht erzwingen.

Um Fehler beim Erstellen expliziter temporärer Tabellen auf Reader-DB-Instances von Aurora MySQL zu vermeiden, stellen Sie sicher, dass alle CREATE TEMPORARY TABLE-Anweisungen mit einer der folgenden Methoden ausgeführt werden:

• Verzichten Sie auf die Angabe der ENGINE=InnoDB-Klausel.

• Legen Sie den SQL-Modus nicht auf NO_ENGINE_SUBSTITUTION fest.

Fehler bei der Erstellung temporärer Tabellen und Abhilfemaßnahmen

Der Fehler, den Sie erhalten, ist unterschiedlich, je nachdem, ob Sie ein einfache CREATE TEMPORARY TABLE-Aussage oder die Variation CREATE TEMPORARY TABLE AS SELECT verwenden. Das folgende Beispiel zeigt die Reihenfolge der verschiedenen Typen:

Dieses temporäre Tabellenverhalten gilt nur für schreibgeschützte Instanzen. Dieses erste Beispiel bestätigt, dass es sich um die Art von Instanz handelt, mit der die Sitzung verbunden ist.

mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
|                  1 |
+--------------------+

Für einfache CREATE TEMPORARY TABLE-Anweisungen schlägt die Anweisung fehl, wenn der NO_ENGINE_SUBSTITUTION-SQL-Modus aktiviert ist. Wenn NO_ENGINE_SUBSTITUTION deaktiviert wird (Standardeinstellung), wird die entsprechende Engine-Ersetzung vorgenommen und die temporäre Tabelle wird erfolgreich erstellt.

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

Für CREATE TEMPORARY TABLE AS SELECT-Anweisungen schlägt die Anweisung fehl, wenn der SQL-Modus NO_ENGINE_SUBSTITUTION aktiviert ist. Wenn NO_ENGINE_SUBSTITUTION deaktiviert wird (Standardeinstellung), wird die entsprechende Engine-Ersetzung vorgenommen und die temporäre Tabelle wird erfolgreich erstellt.

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)

Weitere Informationen zu den Speicheraspekten und Leistungsauswirkungen temporärer Tabellen in Aurora-MySQL-Version 3 finden Sie im Blogbeitrag Verwenden der TempTable-Speicher-Engine in Amazon RDS für MySQL und Amazon Aurora MySQL.