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 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 — Erstellt von der Aurora MySQL-Engine für Operationen wie Sortieraggregation, abgeleitete Tabellen oder allgemeine Tabellenausdrücke ()CTEs. + 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. **Topics** + [Speicher-Engine für interne (implizite) temporäre Tabellen](#ams3-temptable-behavior-engine) + [Begrenzung der Größe interner temporärer Tabellen im Arbeitsspeicher](#ams3-temptable-behavior-limit) + [Abschwächung von Füllungsgradproblemen bei internen temporären Tabellen auf Aurora Replicas](#ams3-temptable-behavior-mitigate) + [Optimieren des temptable\$1max\$1mmap-Parameters auf Aurora MySQL-DB-Instances](#ams-optimize-temptable_max_mmap) + [Vom Benutzer erstellte (explizite) temporäre Tabellen auf Reader-DB-Instances](#ams3-temptable-behavior.user) + [Fehler bei der Erstellung temporärer Tabellen und Abhilfemaßnahmen](#ams3-temptable-behavior.errors) ## 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](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) 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 bei solchen temporären Tabellen zwischen den InnoDB- und MyISAM-Speicher-Engines zu entscheiden, wählen Sie jetzt zwischen den `TempTable`- und `MEMORY`-Speicher-Engines. Mit der `TempTable`-Speicher-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 in`TempTable`Speicherpool 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\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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. Version 3 von Aurora MySQL speichert die Überlaufdaten auf folgende Weise: + Bei der Writer-DB-Instance befinden sich die Dateien, die zu internen temporären Tabellen von InnoDB oder zu speicherzugeordneten Dateien überlaufen, im lokalen Speicher der Instance. + Bei Reader-DB-Instances befinden sich die Überlaufdaten immer in speicherzugeordneten temporären Dateien im lokalen Speicher. Schreibgeschützte Instances können keine Daten auf dem Aurora-Cluster-Volume speichern. Die Konfigurationsparameter für interne temporäre Tabellen gelten unterschiedlich für die Writer- und Reader-Instancees 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\$1use\$1mmap-Parameter](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap) 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](#ams3-temptable-behavior-engine) erwähnt, können Sie temporäre Tabellenressourcen global steuern, indem Sie die Einstellungen [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) und [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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 der`TempTable`-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\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_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\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) oder [max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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. **Example 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) ``` **Example 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) ``` **Example 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) ``` **Example einer Reader-DB-Instance mit der Einstellung `aurora_tmptable_enable_per_table_limit` auf `OFF`** Diese Abfrage erreicht das globale TempTable Ressourcenlimit, wenn sie auf OFF `aurora_tmptable_enable_per_table_limit` gesetzt 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 ``` **Example 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 [Probleme mit freisetzbarem Speicher in Amazon Aurora](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory). 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](Aurora.AuroraMonitoring.Metrics.md). **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](#ams3-temptable-behavior-limit). **Example 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. **Example 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 MySQLTemporäre Speicherlimits](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). ## Optimieren des temptable\$1max\$1mmap-Parameters auf Aurora MySQL-DB-Instances Der `temptable_max_mmap`-Parameter in Aurora MySQL steuert die maximale Menge an lokalem Festplattenspeicher, die von speicherzugeordneten Dateien genutzt werden kann, bevor sie in die temporären InnoDB-Tabellen auf der Festplatte überlaufen (auf Writer-DB-Instances) oder einen Fehler verursachen (auf Reader-DB-Instances). Wenn Sie diesen DB-Instance-Parameter richtig einstellen, kann dies dazu beitragen, die Leistung Ihrer DB-Instances zu optimieren. **Voraussetzungen** 1. Stellen Sie sicher, dass das Leistungsschema aktiviert ist. Sie können dies durch Ausführung des folgenden SQL-Befehls überprüfen: ``` SELECT @@performance_schema; ``` Ein Ausgabewert von `1` gibt an, dass es aktiviert ist. 1. Vergewissern Sie sich, dass die Instrumentierung für den Speicher der temporären Tabellen aktiviert ist. Sie können dies durch Ausführung des folgenden SQL-Befehls überprüfen: ``` SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%'; ``` In der `enabled`-Spalte wird für die relevanten Einträge der Instrumentierung für den temporären Tabellenspeicher `YES` angezeigt. **Überwachen der Verwendung temporärer Tabellen** Wenn Sie den Anfangswert für `temptable_max_mmap` festlegen, sollten Sie mit 80 % der lokalen Speichergröße für die DB-Instance-Klasse beginnen, die Sie verwenden. Dadurch wird sichergestellt, dass die temporären Tabellen über genügend Speicherplatz für einen effizienten Betrieb verfügen und Platz für andere Festplattennutzungen auf der Instance verbleibt. Informationen über die lokale Speichergröße für Ihre DB-Instance-Klasse finden Sie unter [Temporäre Speicherlimits für Aurora MySQLTemporäre Speicherlimits](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). Wenn Sie beispielsweise die DB-Instance-Klasse db.r5.large verwenden, beträgt die lokale Speichergröße 32 GiB. In diesem Fall würden Sie den `temptable_max_mmap`-Parameter zunächst auf 80 % von 32 GiB setzen, was 25,6 GiB entspricht. Nachdem Sie den Anfangswert von `temptable_max_mmap` festgelegt haben, führen Sie Ihren Spitzen-Workload auf den Aurora MySQL-Instances aus. Überwachen Sie die aktuelle und hohe Festplattennutzung durch die temporäre Tabelle mithilfe der folgenden SQL-Abfrage: ``` 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/%'; ``` Diese Abfrage ruft die folgenden Informationen ab: + `event_name` – Der Name des Ereignisses für den temporären Tabellenspeicher oder die Festplattennutzung + `current_count` – Die aktuelle Anzahl der zugewiesenen Blöcke für den temporären Tabellenspeicher oder die Festplatte + `current_alloc` – Die aktuelle Menge an Speicher oder Festplatte, die temporären Tabellen zugewiesen ist + `current_avg_alloc` – Die aktuelle durchschnittliche Größe des temporären Tabellenspeichers oder der Festplattenblöcke + `high_count` – Die höchste Anzahl des zugewiesenen temporären Tabellenspeichers oder der Festplattenblöcke + `high_alloc` – Die größte Menge an Speicher oder Festplatte, die temporären Tabellen zugewiesen ist + `high_avg_alloc` – Die höchste durchschnittliche Größe des temporären Tabellenspeichers oder der Festplattenblöcke Wenn Ihre Abfragen bei Verwendung dieser Einstellung mit dem Fehler „Table is full“ fehlschlagen, bedeutet dies, dass Ihr Workload mehr Festplattenspeicher für temporäre Tabellenoperationen benötigt. In diesem Fall sollten Sie erwägen, die Größe Ihrer DB-Instance auf eine mit mehr lokalem Speicherplatz zu erhöhen. **Den optimalen `temptable_max_mmap`-Wert festlegen** Gehen Sie wie folgt vor, um die richtige Größe für den `temptable_max_mmap`-Parameter festzulegen und ihn zu überwachen: 1. Überprüfen Sie die Ausgabe der vorherigen Abfrage und ermitteln Sie die maximale Festplattennutzung durch temporäre Dateien wie in der `high_alloc`-Spalte angegeben. 1. Passen Sie, basierend auf der maximalen Festplattennutzung durch temporäre Dateien, den `temptable_max_mmap`-Parameter in der DB-Parametergruppe für Ihre DB-Instances von Aurora MySQL an. Stellen Sie den Wert so ein, dass er etwas höher ist als die maximale Festplattennutzung durch temporäre Tabellen, um eine zukünftige Zunahme zu berücksichtigen. 1. Wenden Sie die Änderungen an der Parametergruppe auf Ihre DB-Instances an. 1. Überwachen Sie die Festplattennutzung der temporären Tabelle während des Spitzen-Workloads erneut, um sicherzustellen, dass der neue `temptable_max_mmap`-Wert angemessen ist. 1. Wiederholen Sie die vorherigen Schritte bei Bedarf, um den `temptable_max_mmap`-Parameter zu optimieren. ## 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 Instances. Dieses erste Beispiel bestätigt, dass es sich um die Art von Instance 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 den Auswirkungen temporärer Tabellen auf die Leistung in Aurora MySQL Version 3 finden Sie im Blogbeitrag [Verwenden Sie die TempTable Speicher-Engine auf Amazon RDS for MySQL und Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).