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. # Optimieren der Abfrageleistung in Aurora PostgreSQL Die Optimierung der Abfrageleistung ist von entscheidender Bedeutung, da sie dazu beiträgt, dass Datenbanken schneller und effizienter laufen und gleichzeitig weniger Ressourcen beanspruchen, was zu einer besseren Benutzererfahrung und niedrigeren Betriebskosten führt. Amazon Aurora PostgreSQL bietet mehrere Funktionen zur Optimierung der Abfrageleistung für PostgreSQL-Workloads. **Topics** + [Verbesserung der Abfrageleistung für Aurora PostgreSQL mit Aurora-optimierten Lesevorgängen](AuroraPostgreSQL.optimized.reads.md) + [Optimieren von korrelierten Unterabfragen in Aurora PostgreSQL](apg-correlated-subquery.md) + [Verbessern der Abfrageleistung mit Adaptive Join](user-apg-adaptive-join.md) + [Gemeinsamer Plan-Cache verwenden](apg-shared-plan-cache.md) # Verbesserung der Abfrageleistung für Aurora PostgreSQL mit Aurora-optimierten Lesevorgängen Mit Aurora-optimierten Lesevorgängen können Sie eine schnellere Abfrageverarbeitung mit Aurora PostgreSQL erreichen. Eine Aurora-PostgreSQL-DB-Instance, die Aurora-optimierte Lesevorgänge verwendet, bietet eine bis zu achtmal verbesserte Abfragelatenz und bis zu 30 % Kosteneinsparungen für Anwendungen mit großen Datensätzen, die die Speicherkapazität einer DB-Instance überschreiten. **Topics** + [Übersicht über Aurora-optimierte Lesevorgänge in PostgreSQL](#AuroraPostgreSQL.optimized.reads.overview) + [Verwenden von Aurora-optimierten Lesevorgängen](#AuroraPostgreSQL.optimized.reads.using) + [Anwendungsfälle für Aurora-optimierte Lesevorgänge](#AuroraPostgreSQL.optimized.reads.usecases) + [Überwachen von DB-Instances, die Aurora-optimierte Lesevorgänge verwenden](#AuroraPostgreSQL.optimized.reads.monitoring) + [Bewährte Methoden für Aurora-optimierte Lesevorgänge](#AuroraPostgreSQL.optimized.reads.bestpractices) ## Übersicht über Aurora-optimierte Lesevorgänge in PostgreSQL Aurora Optimized Reads ist standardmäßig verfügbar, wenn Sie einen DB-Cluster erstellen, der Graviton-basierte R6gd-, R8gd- und Intel-basierte R6ID-Instances mit nichtflüchtigem Memory-Express () -Speicher verwendet. NVMe Dies ist in den folgenden Versionen von PostgreSQL verfügbar: + 14.12 und höhere Versionen, 15.7 und höhere Versionen, 16.3 und höhere Versionen, 17.4 und höhere Versionen für R8gd-Instances + 14.9 und höhere Versionen, 15.4 und höhere Versionen, 16.1 und alle höheren Versionen für R6gd- und R6id-Instances Aurora-optimierte Lesevorgänge unterstützen zwei Funktionen: mehrstufigen Cache und temporäre Objekte. **Mehrstufiger Cache mit optimierten Lesevorgängen** – Mithilfe eines mehrstufigen Caches können Sie die Caching-Kapazität Ihrer DB-Instance um das bis zu Fünffache des Instance-Speichers erweitern. Dadurch wird der Cache automatisch so verwaltet, dass er die aktuellsten, transaktionskonsistenten Daten enthält. Dadurch entfällt für Anwendungen der Aufwand, die Datenaktualität externer, auf Ergebnismengen basierender Caching-Lösungen zu verwalten. Dies bietet eine bis zu achtmal bessere Latenz für Abfragen, bei denen zuvor Daten aus dem Aurora-Speicher abgerufen wurden. In Aurora ist der Wert für `shared_buffers` in der Standard-Parametergruppe normalerweise auf etwa 75 % des verfügbaren Speichers festgelegt. Für die Instance-Typen r8gd, r6gd und r6id reduziert Aurora den `shared_buffers` Speicherplatz jedoch um 4,5%, um die Metadaten für den Optimized Reads-Cache zu hosten. **Optimierte temporäre Objekte mit Lesezugriff** — Mithilfe temporärer Objekte können Sie eine schnellere Abfrageverarbeitung erreichen, indem Sie die temporären Dateien, die von PostgreSQL generiert werden, im lokalen Speicher ablegen. NVMe Dadurch wird der Datenverkehr zu Elastic Block Storage (EBS) über das Netzwerk reduziert. Dies bietet eine bis zu zweimal bessere Latenz und einen besseren Durchsatz für erweiterte Abfragen, bei denen große Datenmengen sortiert, verbunden oder zusammengeführt werden, die nicht in die auf einer DB-Instance verfügbare Speicherkapazität passen. In einem I/O-optimierten Aurora-Cluster verwendet Optimized Reads sowohl den mehrstufigen Cache als auch temporäre Objekte im Speicher. NVMe Mit der für optimierte Lesevorgänge aktivierten mehrstufigen Cache-Funktion weist Aurora den doppelten Instance-Speicher für temporäre Objekte zu, etwa 10 % des Speichers für interne Operationen und den verbleibenden Speicher als mehrstufigen Cache. In einem Aurora-Standard-Cluster verwenden optimierte Lesevorgänge nur temporäre Objekte. E/A-optimierte Aurora-Cluster ermöglichen es Ihnen, den zugewiesenen Speicherplatz für temporäre Objekte mit aktivierten optimierten Lesevorgängen mithilfe des dynamischen Parameters `aurora_temp_space_size` auf Instance-Ebene anzupassen. Diese Größenanpassungsfunktion ist in den folgenden PostgreSQL-Versionen verfügbar: + 16.8 und alle höheren Versionen + 15.12 und höhere 15-Versionen + 14.17 und höhere 14-Versionen Mit diesem Parameter können Sie die Kapazität von 2x bis 6x des Instance-Speichers skalieren, ohne dass die Datenbank-Engine neu gestartet werden muss. Wenn Sie den Speicherplatz für temporäre Objekte erweitern, wird die Änderung sofort wirksam, unabhängig von gleichzeitigen Workloads. Wenn Sie den Speicherplatz reduzieren, wird die Anpassung jedoch erst abgeschlossen, wenn in den temporären Objekten genügend ungenutzter Speicherplatz für die neue Größenanforderung vorhanden ist. Nachdem Sie die Größe temporärer Objekte mit aktivierten optimierten Lesevorgängen geändert haben, passt sich der mehrstufige Cache automatisch an, um den verfügbaren Speicherplatz zu nutzen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.optimized.reads.html) **Anmerkung** Ein Wechsel zwischen IO-optimierten Clustern und Standard-Clustern auf einer NVMe basierten DB-Instance-Klasse führt zu einem sofortigen Neustart der Datenbank-Engine. Verwenden Sie in Aurora PostgreSQL den `temp_tablespaces`-Parameter zur Konfiguration des Tabellenbereichs, in dem die temporären Objekte gespeichert werden. Verwenden Sie den folgenden Befehl, um zu überprüfen, ob die temporären Objekte konfiguriert sind: ``` postgres=> show temp_tablespaces; temp_tablespaces --------------------- aurora_temp_tablespace (1 row) ``` Das `aurora_temp_tablespace` ist ein von Aurora konfigurierter Tablespace, der auf den NVMe lokalen Speicher verweist. Sie können diesen Parameter nicht ändern oder zum Amazon-EBS-Speicher zurückkehren. Verwenden Sie den folgenden Befehl, um zu überprüfen, ob der Cache der optimierten Lesevorgänge aktiviert ist: ``` postgres=> show shared_preload_libraries; shared_preload_libraries -------------------------------------------------------- rdsutils,pg_stat_statements,aurora_optimized_reads_cache ``` ## Verwenden von Aurora-optimierten Lesevorgängen Wenn Sie eine Aurora PostgreSQL-DB-Instance mit einer der NVMe basierten DB-Instances bereitstellen, verwendet die DB-Instance automatisch Aurora Optimized Reads. Führen Sie einen der folgenden Schritte aus, um Aurora-optimierte Lesevorgänge zu aktivieren: + Erstellen Sie einen Aurora PostgreSQL-DB-Cluster mithilfe einer der NVMe basierten DB-Instance-Klassen. Weitere Informationen finden Sie unter [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md). + Ändern Sie einen vorhandenen Aurora PostgreSQL-DB-Cluster so, dass er eine der NVMe basierten DB-Instance-Klassen verwendet. Weitere Informationen finden Sie unter [Ändern eines Amazon Aurora-DB-Clusters](Aurora.Modifying.md). Aurora Optimized Reads ist überall verfügbar AWS-Regionen , wo eine oder mehrere DB-Instance-Klassen mit lokalem NVMe SSD-Speicher unterstützt werden. Weitere Informationen finden Sie unter [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md). Um zurück zu einer Aurora-Instance mit nicht optimierten Lesevorgängen zu wechseln, ändern Sie die DB-Instance-Klasse Ihrer Aurora-Instance auf eine ähnliche Instance-Klasse ohne NVMe kurzlebigen Speicher für Ihre Datenbank-Workloads. Wenn die aktuelle DB-Instance-Klasse beispielsweise db.r6gd.4xlarge ist, wählen Sie db.r6g.4xlarge aus, um zurückzuwechseln. Weitere Informationen finden Sie unter [Ändern einer Amazon-DB-Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html). ## Anwendungsfälle für Aurora-optimierte Lesevorgänge **Optimierter mehrstufiger Cache mit optimierten Lesevorgängen** Im Folgenden sind einige Anwendungsfälle aufgeführt, für die optimierte Lesevorgänge mit gestuftem Cache von Vorteil sein können: + Anwendungen im Internet-Maßstab wie Zahlungsabwicklung, Rechnungsstellung und E-Commerce mit strikter Leistung. SLAs + Dashboards für Berichte in Echtzeit, auf denen Hunderte von Einzelabfragen zur metrics/data Erfassung ausgeführt werden. + Generative KI-Anwendungen mit der Erweiterung pgvector zur Suche nach exakten oder nächstgelegenen Nachbarn in Millionen von Vektoreinbettungen. **Temporäre Objekte mit optimierten Lesevorgängen** Im Folgenden sind einige Anwendungsfälle aufgeführt, für die optimierte Lesevorgänge von Vorteil sein können: + Analytische Abfragen, die allgemeine Tabellenausdrücke (CTEs), abgeleitete Tabellen und Gruppierungsoperationen enthalten. + Lesereplikate, die die nicht optimierten Abfragen für eine Anwendung verarbeiten. + Bedarfsgesteuerte oder dynamische Berichtsabfragen mit komplexen Operationen wie GROUP BY und ORDER BY, für die nicht immer die entsprechenden Indizes verwendet werden können. + `CREATE INDEX`- oder `REINDEX`-Operationen zum Sortieren + Andere Workloads, die interne temporäre Tabellen verwenden. ## Überwachen von DB-Instances, die Aurora-optimierte Lesevorgänge verwenden Sie können Ihre Abfragen, die den mehrstufigen Cache mit optimierten Lesevorgängen zum Aktivieren von Lesevorgängen verwenden, wie im folgenden Beispiel dargestellt mit dem Befehl EXPLAIN überwachen: ``` Postgres=> EXPLAIN (ANALYZE, BUFFERS) SELECT c FROM sbtest15 WHERE id=100000000 QUERY PLAN -------------------------------------------------------------------------------------- Index Scan using sbtest15_pkey on sbtest15 (cost=0.57..8.59 rows=1 width=121) (actual time=0.287..0.288 rows=1 loops=1) Index Cond: (id = 100000000) Buffers: shared hit=3 read=2 aurora_orcache_hit=2 I/O Timings: shared/local read=0.264 Planning: Buffers: shared hit=33 read=6 aurora_orcache_hit=6 I/O Timings: shared/local read=0.607 Planning Time: 0.929 ms Execution Time: 0.303 ms (9 rows) Time: 2.028 ms ``` **Anmerkung** Die Felder `aurora_orcache_hit` und `aurora_storage_read` im `Buffers`-Abschnitt des Erklärungsplans werden nur angezeigt, wenn optimierte Lesevorgänge aktiviert und ihre Werte größer als Null sind. Das read-Feld ist die Summe der Felder `aurora_orcache_hit` und `aurora_storage_read`. Sie können DB-Instances, die Aurora Optimized Reads verwenden, anhand der folgenden CloudWatch Metriken überwachen: + `AuroraOptimizedReadsCacheHitRatio` + `FreeEphemeralStorage` + `ReadIOPSEphemeralStorage` + `ReadLatencyEphemeralStorage` + `ReadThroughputEphemeralStorage` + `WriteIOPSEphemeralStorage` + `WriteLatencyEphemeralStorage` + `WriteThroughputEphemeralStorage` Diese Metriken liefern Daten über den verfügbaren Instance-Speicher, die IOPS und den Durchsatz. Weitere Informationen zu diesen Metriken finden Sie unter [Metriken auf Instance-Ebene für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). Sie können die `pg_proctab` Erweiterung auch zur NVMe Speicherüberwachung verwenden. ``` postgres=>select * from pg_diskusage(); major | minor | devname | reads_completed | reads_merged | sectors_read | readtime | writes_completed | writes_merged | sectors_written | writetime | current_io | iotime | totaliotime ------+-------+---------------------+-----------------+--------------+--------------+----------+------------------+---------------+-----------------+-----------+------------+---------+------------- | | rdstemp | 23264 | 0 | 191450 | 11670 | 1750892 | 0 | 24540576 | 819350 | 0 | 3847580 | 831020 | | rdsephemeralstorage | 23271 | 0 | 193098 | 2620 | 114961 | 0 | 13845120 | 130770 | 0 | 215010 | 133410 (2 rows) ``` ## Bewährte Methoden für Aurora-optimierte Lesevorgänge Nutzen Sie die folgenden bewährten Methoden für Aurora-optimierte Lesevorgänge: + Überwachen Sie den im Instance-Speicher verfügbaren Speicherplatz anhand der CloudWatch Metrik`FreeEphemeralStorage`. Wenn der Instance-Speicher aufgrund des Workloads der DB-Instance sein Limit erreicht, stellen Sie die Gleichzeitigkeit und die Abfragen ein, die intensiven Gebrauch von temporären Objekten machen, oder ändern Sie die Instance so, dass sie eine größere DB-Instance-Klasse verwendet. + Überwachen Sie die CloudWatch Metrik im Hinblick auf die Cache-Trefferquote für optimierte Lesevorgänge. Operationen wie VACUUM ändern sehr schnell eine große Anzahl von Blöcken. Dies kann zu einem vorübergehenden Rückgang der Trefferrate führen. Die `pg_prewarm`-Erweiterung kann verwendet werden, um Daten in den Puffer-Cache zu laden, so dass Aurora einige dieser Blöcke proaktiv in den Cache der optimierten Lesevorgänge schreiben kann. + Sie können das Cluster-Cache-Management (CCM) aktivieren, um den Puffer-Cache und den mehrstufigen Cache auf einem Tier-0-Reader aufzuwärmen, der als Failover-Ziel verwendet wird. Wenn CCM aktiviert ist, wird der Puffer-Cache regelmäßig gescannt, um Seiten, die bereinigt werden können, in den mehrstufigen Cache zu schreiben. Weitere Informationen zu CCM finden Sie unter [Schnelle Wiederherstellung nach Failover mit der Cluster-Cacheverwaltung für Aurora PostgreSQL](AuroraPostgreSQL.cluster-cache-mgmt.md). # Optimieren von korrelierten Unterabfragen in Aurora PostgreSQL Eine korrelierte Unterabfrage verweist auf Tabellenspalten aus der äußeren Abfrage. Sie wird einmal für jede Zeile ausgewertet, die von der äußeren Abfrage zurückgegeben wird. Im folgenden Beispiel verweist die Unterabfrage auf eine Spalte aus der Tabelle „ot“. Diese Tabelle ist nicht in der FROM-Klausel der Unterabfrage enthalten, wird aber in der FROM-Klausel der äußeren Abfrage referenziert. Wenn die Tabelle „ot“ 1 Million Zeilen enthält, muss die Unterabfrage 1 Million Mal ausgewertet werden. ``` SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); ``` **Anmerkung** Die Transformation einer Unterabfrage und der Unterabfragen-Cache sind in Aurora PostgreSQL ab Version 16.8 verfügbar, während Babelfish für Aurora PostgreSQL diese Funktionen ab Version 4.2.0 unterstützt. Ab den Versionen 4.6.0 und 5.2.0 von Babelfish für Aurora PostgreSQL steuern die folgenden Parameter diese Funktionen: babelfishpg\$1tsql.apg\$1enable\$1correlated\$1scalar\$1transform babelfishpg\$1tsql.apg\$1enable\$1subquery\$1cache Beide Parameter sind standardmäßig deaktiviert. ## Verbessern der Aurora-PostgreSQL-Abfrageleistung mithilfe der Unterabfragentransformation Aurora PostgreSQL kann korrelierte Unterabfragen beschleunigen, indem sie in äquivalente äußere Joins umgewandelt werden. Diese Optimierung gilt für die folgenden zwei Typen korrelierter Unterabfragen: + Unterabfragen, die einen einzelnen Aggregatwert zurückgeben und in der SELECT-Liste aufgeführt sind ``` SELECT ot.a, ot.b, (SELECT AVG(it.b) FROM it WHERE it.a = ot.a) FROM ot; ``` + Unterabfragen, die einen einzelnen Aggregatwert zurückgeben und in einer WHERE-Klausel aufgeführt sind ``` SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); ``` ### Aktivieren der Transformation in der Unterabfrage Um die Transformation korrelierter Unterabfragen in äquivalente externe Joins zu ermöglichen, setzen Sie den `apg_enable_correlated_scalar_transform`-Parameter auf `ON`. Der Standardwert für diesen Parameter ist `OFF`. Sie können die Cluster- oder Instance-Parametergruppe ändern, um diese Parameter festzulegen. Weitere Informationen hierzu finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). Alternativ können Sie die Einstellung mit dem folgenden Befehl ausschließlich für die aktuelle Sitzung konfigurieren: ``` SET apg_enable_correlated_scalar_transform TO ON; ``` ### Überprüfen der Transformation Verwenden Sie den Befehl EXPLAIN, um zu überprüfen, ob die korrelierte Unterabfrage im Abfrageplan in einen externen Join umgewandelt wurde. Wenn die Transformation aktiviert ist, wird der entsprechende korrelierte Teil der Unterabfrage in einen externen Join umgewandelt. Beispiel: ``` postgres=> CREATE TABLE ot (a INT, b INT); CREATE TABLE postgres=> CREATE TABLE it (a INT, b INT); CREATE TABLE postgres=> SET apg_enable_correlated_scalar_transform TO ON; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); QUERY PLAN -------------------------------------------------------------- Hash Join Hash Cond: (ot.a = apg_scalar_subquery.scalar_output) Join Filter: ((ot.b)::numeric < apg_scalar_subquery.avg) -> Seq Scan on ot -> Hash -> Subquery Scan on apg_scalar_subquery -> HashAggregate Group Key: it.a -> Seq Scan on it ``` Dieselbe Abfrage wird nicht umgewandelt, wenn der GUC-Parameter auf `OFF` gesetzt wird. Der Plan hat keinen externen Join, sondern stattdessen einen untergeordneten Plan (Subplan). ``` postgres=> SET apg_enable_correlated_scalar_transform TO OFF; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); QUERY PLAN ---------------------------------------- Seq Scan on ot Filter: ((b)::numeric < (SubPlan 1)) SubPlan 1 -> Aggregate -> Seq Scan on it Filter: (a = ot.a) ``` ### Einschränkungen + Die Unterabfrage muss in der SELECT-Liste oder in einer der Bedingungen der WHERE-Klausel enthalten sein. Andernfalls wird sie nicht umgewandelt. + Die Unterabfrage muss eine Aggregatfunktion zurückgeben. Benutzerdefinierte Aggregatfunktionen unterstützen keine Transformation. + Eine Unterabfrage, deren Return-Ausdruck keine einfache Aggregatfunktion ist, wird nicht umgewandelt. + Die korrelierte Bedingung in den WHERE-Klauseln der Unterabfrage sollte ein einfacher Spaltenverweis sein. Andernfalls wird sie nicht umgewandelt. + Die korrelierte Bedingung in den Where-Klauseln der Unterabfrage muss ein einfaches Gleichheitsprädikat sein. + Die Unterabfrage darf weder eine HAVING- noch eine GROUP BY-Klausel enthalten. + Die WHERE-Klausel in der Unterabfrage kann ein oder mehrere Prädikate in Kombination mit AND enthalten. **Anmerkung** Die Auswirkungen der Transformation auf die Leistung hängen von Ihrem Schema, Ihren Daten und Ihrem Workload ab. Die Ausführung korrelierter Unterabfragen mit Transformation kann die Leistung erheblich verbessern, da die Anzahl der Zeilen, die von der äußeren Abfrage erzeugt werden, zunimmt. Es wird dringend empfohlen, diese Funktion in einer Nicht-Produktionsumgebung mit Ihrem tatsächlichen Schema, Ihren Daten und Ihrem Workload zu testen, ehe Sie sie in einer Produktionsumgebung aktivieren. ## Verwenden des Unterabfrage-Caches zur Verbesserung der Aurora-PostgreSQL-Abfrageleistung Aurora PostgreSQL unterstützt einen Unterabfrage-Cache zum Speichern der Ergebnisse korrelierter Unterabfragen. Diese Funktion überspringt wiederholte Ausführungen korrelierter Unterabfragen, wenn sich die Ergebnisse der Unterabfragen bereits im Cache befinden. ### Grundlegendes zu Unterabfragen Der Memoize-Knoten von PostgreSQL ist der wichtigste Teil des Unterabfrage-Caches. Der Memoize-Knoten verwaltet eine Hash-Tabelle im lokalen Cache, um Eingabeparameterwerte den Abfrageergebniszeilen zuzuordnen. Das Speicherlimit für die Hash-Tabelle ergibt sich aus work\$1mem und hash\$1mem\$1multiplier. Weitere Informationen finden Sie unter [Ressourcennutzung](https://www.postgresql.org/docs/16/runtime-config-resource.html). Während der Ausführung der Abfrage verwendet der Unterabfragen-Cache die Cache-Trefferrate (CHR), um abzuschätzen, ob der Cache die Abfrageleistung verbessert, und um zur Laufzeit der Abfrage zu entscheiden, ob der Cache weiterhin verwendet werden soll. Die CHR gibt das Verhältnis der Anzahl von Cache-Treffern zur Gesamtzahl der Anfragen an. Wenn beispielsweise eine korrelierte Unterabfrage 100 Mal ausgeführt werden muss und 70 dieser Ausführungsergebnisse aus dem Cache abgerufen werden können, beträgt die CHR 0,7. Für jede apg\$1subquery\$1cache\$1check\$1interval-Anzahl von Cache-Fehlern wird der Nutzen des Unterabfrage-Caches ausgewertet, indem geprüft wird, ob die CHR größer ist als apg\$1subquery\$1cache\$1hit\$1rate\$1threshold. Wenn nicht, wird der Cache aus dem Speicher gelöscht und die Abfrageausführung kehrt zur ursprünglichen, nicht zwischengespeicherten erneuten Ausführung der Unterabfrage zurück. ### Parameter, die das Verhalten des Unterabfrage-Caches steuern In der folgenden Tabelle sind die Parameter aufgeführt, die das Verhalten des Unterabfrage-Caches steuern. | Parameter | Description | Standard | Zulässig | | --- | --- | --- | --- | | apg\$1enable\$1subquery\$1cache | Aktiviert die Verwendung von Cache für korrelierte skalare Unterabfragen | OFF | ON, OFF | | apg\$1subquery\$1cache\$1check\$1interval | Legt die Häufigkeit in Anzahl der Cache-Fehler fest, um die Unterabfragen-CHR zu bewerten. | 500 | 0 – 2147483647 | | apg\$1subquery\$1cache\$1hit\$1rate\$1threshold | Legt den Schwellenwert für die Unterabfragen-CHR fest. | 0.3 | 0,0 bis 1,0 | **Anmerkung** Höhere Werte von `apg_subquery_cache_check_interval` können die Genauigkeit der CHR-basierten Einschätzung des Cache-Nutzens verbessern, erhöhen aber den Cache-Overhead, da die CHR erst ausgewertet wird, wenn die Cache-Tabelle `apg_subquery_cache_check_interval`-Zeilen enthält. Höhere Werte von `apg_subquery_cache_hit_rate_threshold` bedeuten, dass der Unterabfrage-Cache aufgegeben wurde und zur ursprünglichen, erneuten Ausführung der Unterabfrage ohne Zwischenspeicherung zurückgekehrt wird. Sie können die Cluster- oder Instance-Parametergruppe ändern, um diese Parameter festzulegen. Weitere Informationen hierzu finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). Alternativ können Sie die Einstellung mit dem folgenden Befehl ausschließlich für die aktuelle Sitzung konfigurieren: ``` SET apg_enable_subquery_cache TO ON; ``` ### Aktivieren des Unterabfrage-Caches in Aurora PostgreSQL Wenn der Unterabfrage-Cache aktiviert ist, nutzt Aurora PostgreSQL Cache, um die Ergebnisse der Unterabfrage zu speichern. Unter SubPlan dem Abfrageplan befindet sich dann ein Memoize-Knoten. Die folgende Befehlssequenz zeigt beispielsweise den geschätzten Abfrageausführungsplan einer einfachen korrelierten Unterabfrage ohne Unterabfrage-Cache. ``` postgres=> SET apg_enable_subquery_cache TO OFF; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ------------------------------------ Seq Scan on ot Filter: (b < (SubPlan 1)) SubPlan 1 -> Seq Scan on it Filter: (a = ot.a) ``` Nach dem `apg_enable_subquery_cache` Einschalten enthält der Abfrageplan einen Memoize-Knoten unter dem Knoten, der SubPlan darauf hinweist, dass die Unterabfrage beabsichtigt, den Cache zu verwenden. ``` postgres=> SET apg_enable_subquery_cache TO ON; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ------------------------------------ Seq Scan on ot Filter: (b < (SubPlan 1)) SubPlan 1 -> Memoize Cache Key: ot.a Cache Mode: binary -> Seq Scan on it Filter: (a = ot.a) ``` Der eigentliche Ausführungsplan für die Abfrage enthält weitere Details zum Unterabfrage-Cache, einschließlich Cache-Treffer und Cache-Fehler. Die folgende Ausgabe zeigt den tatsächlichen Abfrageausführungsplan der obigen Beispielabfrage nach dem Einfügen einiger Werte in die Tabellen. ``` postgres=> EXPLAIN (COSTS FALSE, TIMING FALSE, ANALYZE TRUE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ----------------------------------------------------------------------------- Seq Scan on ot (actual rows=2 loops=1) Filter: (b < (SubPlan 1)) Rows Removed by Filter: 8 SubPlan 1 -> Memoize (actual rows=0 loops=10) Cache Key: ot.a Cache Mode: binary Hits: 4 Misses: 6 Evictions: 0 Overflows: 0 Memory Usage: 1kB -> Seq Scan on it (actual rows=0 loops=6) Filter: (a = ot.a) Rows Removed by Filter: 4 ``` Die Gesamtzahl der Cache-Treffer ist 4 und die Gesamtzahl der Cache-Fehler beträgt 6. Wenn die Gesamtzahl der Treffer und Fehler geringer ist als die Anzahl der Schleifen im Memoize-Knoten, bedeutet das, dass die CHR-Evaluierung nicht erfolgreich war und der Cache an irgendeinem Punkt bereinigt und aufgegeben wurde. Hinsichtlich der Ausführung der Unterabfrage wurde dann die ursprüngliche, erneute Ausführung ohne Zwischenspeicherung wiederaufgenommen. ### Einschränkungen Der Unterabfrage-Cache unterstützt bestimmte Muster korrelierter Unterabfragen nicht. Diese Arten von Abfragen werden ohne Cache ausgeführt, auch wenn der Unterabfrage-Cache aktiviert ist: + IN/EXISTS/ANY/ALLkorrelierte Unterabfragen + Korrelierte Unterabfragen, die nicht deterministische Funktionen enthalten + Korrelierte Unterabfragen, die auf äußere Tabellenspalten mit Datentypen verweisen, die keine Hashing- oder Gleichheitsoperationen unterstützen. # Verbessern der Abfrageleistung mit Adaptive Join ## -Übersicht Adaptive Join ist eine Vorschaufunktion in Aurora PostgreSQL 17.4, die zur Verbesserung der Abfrageleistung beiträgt. Diese Funktion ist standardmäßig deaktiviert, Sie können sie jedoch mithilfe von GUC-Parametern (Global User Configuration) aktivieren. Da es sich um eine Vorschaufunktion handelt, können sich die Standardparameterwerte ändern. Wenn diese Option aktiviert ist, trägt Adaptive Join zur Optimierung der Abfrageleistung bei, indem zur Laufzeit dynamisch von einem Nested-Loop-Join zu einem Hash-Join gewechselt wird. Dieser Wechsel erfolgt, wenn der PostgreSQL-Optimierer aufgrund ungenauer Kardinalitätsschätzungen fälschlicherweise einen Nested-Loop-Join ausgewählt hat. ## Konfigurieren von Adaptive Join Sie können Adaptive Join über diese drei GUC-Parameter steuern: **Konfigurationsparameter für Adaptive Join** | GUC-Parameter | Description | Standard-Konfigurationsoptionen | | --- | --- | --- | | apg\$1adaptive\$1join\$1crossover\$1multiplier | Dieser Multiplikator bestimmt zusammen mit dem Zeilenknotenpunkt, wann von einem verschachtelten Loop zu einem Hash-Join gewechselt werden soll. Am Zeilenübergangspunkt schätzt der SQL-Optimierer, dass Vorgänge für verschachtelte Schleifen und Hash-Joins dieselben Kosten verursachen. Ein höherer Multiplikatorwert verringert die Wahrscheinlichkeit, dass Adaptive Join zu einem Hash-Join wechselt. | Steuert, ob Adaptive Join aktiviert ist [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) | | apg\$1adaptive\$1join\$1cost\$1threshold | Dieser Parameter legt einen Mindestschwellenwert für Abfragekosten fest. Adaptive Join deaktiviert sich automatisch für Abfragen, die unter diesem Schwellenwert liegen. Dadurch wird ein Leistungsaufwand bei einfachen Abfragen vermieden, bei denen die Kosten für die Planung eines adaptiven Joins die Vorteile des Wechsels von Nested Loop zu Hash-Join übersteigen könnten. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) | | apg\$1enable\$1parameterized\$1adaptive\$1join | Dieser Parameter erweitert Adaptive Join-Funktionen auf parametrisierte Nested Loop Joins, wenn er aktiviert ist. Standardmäßig funktioniert Adaptive Join nur mit nicht parametrisierten Nested Loop Joins, da diese eher von der Umstellung auf Hash-Join profitieren. Parametrisierte Nested Loop Joins schneiden in der Regel besser ab, sodass die Umstellung auf Hash-Join weniger kritisch ist. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) `apg_adaptive_join_crossover_multiplier` muss zuerst aktiviert werden | # Gemeinsamer Plan-Cache verwenden ## -Übersicht Aurora PostgreSQL verwendet ein process-per-user Modell, bei dem jede Client-Verbindung einen dedizierten Backend-Prozess erzeugt. Jeder Backend-Prozess verwaltet seinen eigenen lokalen Plan-Cache für vorbereitete Anweisungen. Da diese Caches nicht von Prozessen gemeinsam genutzt werden können, können Anwendungen, die viele vorbereitete Anweisungen verwenden, doppelte Caches für verschiedene Backend-Prozesse erstellen, was zu einer erhöhten Speicherauslastung führt. Die Aurora PostgreSQL-Versionen 17.6 und höher sowie 16.10 und höher führen die Cache-Funktionalität für gemeinsame Pläne ein. Wenn Sie diese Funktion aktivieren, können Back-End-Prozesse generische Pläne gemeinsam nutzen, wodurch der Speicherverbrauch reduziert und die Leistung verbessert wird, da keine doppelten Pläne generiert werden. Der Cache für gemeinsam genutzte Pläne verwendet die folgenden Komponenten als Cache-Schlüssel: + Abfragezeichenfolge (einschließlich Kommentare) + GUC-Parameter im Zusammenhang mit dem Planer (einschließlich) `search_path` + Benutzer-ID + Datenbank-ID Neustarts der Instanz setzen den gemeinsam genutzten Cache zurück. ## Parameters In der folgenden Tabelle werden die Parameter beschrieben, die die Cache-Funktion für gemeinsam genutzte Pläne steuern: | Parameter | Description | Standard | Zulässig | | --- | --- | --- | --- | | apg\$1shared\$1plan\$1cache.enable | Schaltet den Cache für gemeinsam genutzte Pläne ein oder aus | 0 (AUS) | 0, 1 | | apg\$1shared\$1plan\$1cache.max | Die maximale Anzahl von Cache-Einträgen | 200—1000 (abhängig von der Instanzgröße) | 100—50000 | | apg\$1shared\$1plan\$1cache.min\$1size\$1per\$1entry | Die Mindestgröße des Plans, der im gemeinsam genutzten Cache gespeichert werden soll. Kleinere Pläne verwenden den lokalen Cache, um die OLTP-Leistung zu optimieren. | 16 KB | 0—32768 (KB) | | apg\$1shared\$1plan\$1cache.max\$1size\$1per\$1entry | Die maximale Plangröße für den gemeinsam genutzten Cache. Größere Pläne speichern nur Kosteninformationen. | 256 KB — 4 MB (abhängig von der Instanzgröße) | 0—32768 (KB) | | apg\$1shared\$1plan\$1cache.idle\$1generic\$1plan\$1release\$1timeout | Die Zeit, nach der Leerlaufsitzungen lokale generische Pläne veröffentlichen. Niedrigere Werte sparen Speicherplatz. Höhere Werte können die Leistung verbessern. | 10 Sekunden | 0—2147483647 (ms) | **Anmerkung** Sie können alle Parameter ändern, ohne einen Neustart durchführen zu müssen. ## Ansichten und Funktionen überwachen + `apg_shared_plan_cache()`— Zeigt detaillierte Informationen zu Cache-Einträgen (Treffer, Gültigkeit, Zeitstempel) + `apg_shared_plan_cache_stat()`— Zeigt Statistiken auf Instanzebene an (Räumungen, Invalidierungen) + `apg_shared_plan_cache_reset()`— Entfernt alle Einträge in und `apg_shared_plan_cache()` `apg_shared_plan_cache_stat()` + `apg_shared_plan_cache_remove(cache_key)`— Entfernt einen Eintrag, von `apg_shared_plan_cache()` dem der Eintrag mit dem übereinstimmt `cache_key` ## Einschränkungen + Funktioniert nur mit vorbereiteten Anweisungen und speichert keine PL/pgSQL Anweisungen im Cache + Zwischenspeichert keine Abfrage, die temporäre Tabellen oder Katalogtabellen enthält + Zwischenspeichert keine Abfrage, die von RLS (Row-Level Security) abhängt + Jedes Replikat verwaltet seinen eigenen Cache (keine replikatübergreifende gemeinsame Nutzung)