Neues Verhalten bei temporären Tabellen in Aurora My SQL Version 3 - Amazon Aurora
Speicher-Engine für interne (implizite) temporäre TabellenBegrenzung der Größe interner temporärer Tabellen im ArbeitsspeicherAbschwächung von Füllungsgradproblemen bei internen temporären Tabellen auf Aurora ReplicasVom Benutzer erstellte (explizite) temporäre Tabellen auf Reader-DB-InstancesFehler bei der Erstellung temporärer Tabellen und Abhilfemaßnahmen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Neues Verhalten bei temporären Tabellen in Aurora My SQL Version 3

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

  • Interne (oder implizite) temporäre Tabellen — Erstellt von der Aurora My SQL Engine für Operationen wie Sortieraggregation, abgeleitete Tabellen oder allgemeine Tabellenausdrücke ()CTEs.

  • Vom Benutzer erstellte (oder explizite) temporäre Tabellen — Diese werden von der Aurora My SQL Engine erstellt, wenn Sie die CREATE TEMPORARY TABLE Anweisung 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 My SQL zunächst, in temporäre Tabellen im Speicher 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 dazu finden Sie unter Verwendung interner temporärer Tabellen in My SQL in der SQL Dokumentation My.

In Aurora My SQL Version 3 unterscheidet sich die Funktionsweise interner temporärer Tabellen von früheren Aurora SQL My-Versionen. Anstatt für solche temporären Tabellen zwischen den ISAM Speicher-Engines InnoDB und My zu wählen, wählen Sie jetzt zwischen den TempTable und den MEMORY Speicher-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. Wenn ja, SQL speichert Aurora My 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 My SQL speichert die Überlaufdaten unterschiedlich, je nachdem, welches Datenüberlaufziel Sie wählen 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.

  • Auf der Writer-Instance befinden sich Daten, die zu temporären Dateien mit Speicherabbildung überlaufen, im lokalen Speicher auf der Aurora My Version 3-Instance. SQL

  • 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.

  • Auf Reader-Instances verwendet Aurora My SQL immer die TempTable Speicher-Engine.

  • 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. Es ist veraltet, und es wird erwartet, dass die Unterstützung dafür in einer future Version von My SQL 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 tmp_table_size Parameter definiert die maximale Größe temporärer Tabellen, die von der MEMORY Speicher-Engine in Aurora My SQL Version 3 erstellt wurden.

Definiert in Aurora My SQL Version 3.04 und höher tmp_table_size auch die maximale Größe von temporären Tabellen, die von der TempTable Speicher-Engine erstellt werden, wenn der aurora_tmptable_enable_per_table_limit DB-Parameter auf ON gesetzt ist. Dieses Verhalten ist standardmäßig deaktiviert (OFF), was dasselbe Verhalten wie in Aurora My SQL Version 3.03 und niedrigeren Versionen ist.

  • 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 My SQL zeigt das folgende Verhalten, wenn das globale TempTable Ressourcenlimit erreicht ist:

    • Writer-DB-Instances — Aurora My konvertiert die temporäre In-Memory-Tabelle SQL 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 jaON, verhält SQL sich Aurora My wie folgt, wenn das tmp_table_size Limit erreicht ist:

    • Writer-DB-Instances — Aurora My konvertiert die temporäre In-Memory-Tabelle SQL 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 mit aurora_tmptable_enable_per_table_limit der Einstellung auf. OFF 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 der Wert zu hoch eingestellt wird, wird der verfügbare Speicher auf der Datenbankinstanz reduziert, was zu Störungen führen out-of-memory 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 .

Es ist auch wichtig, die Größe des lokalen Speichers und die Speicherplatzbelegung durch die temporäre Tabelle zu überwachen. Sie können den für eine bestimmte DB-Instance verfügbaren temporären Speicher mit der FreeLocalStorage CloudWatch Amazon-Metrik überwachen, die unter beschrieben ist CloudWatch Amazon-Metriken für Amazon Aurora.

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 My SQL.

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 Aurora My SQL Reader-DB-Instances zu vermeiden, stellen Sie sicher, dass Sie alle CREATE TEMPORARY TABLE Anweisungen auf eine oder beide der folgenden Arten ausführen:

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

  • Stellen Sie den SQL Modus nicht auf einNO_ENGINE_SUBSTITUTION.

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 |
+--------------------+

Bei einfachen 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

Bei CREATE TEMPORARY TABLE AS SELECT 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 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 den Auswirkungen temporärer Tabellen auf die Leistung in Aurora My SQL Version 3 finden Sie im Blogbeitrag Verwenden Sie die TempTable Speicher-Engine auf Amazon RDS for My SQL und Amazon Aurora My SQL.