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.
Arbeiten mit Aurora DSQL EXPLAIN-Plänen
Aurora DSQL verwendet eine ähnliche EXPLAIN-Planstruktur wie PostgreSQL, jedoch mit wichtigen Ergänzungen, die die verteilte Architektur und das Ausführungsmodell widerspiegeln.
In dieser Dokumentation geben wir einen Überblick über die EXPLAIN-Pläne von Aurora DSQL und heben die Gemeinsamkeiten und Unterschiede im Vergleich zu PostgreSQL hervor. Wir werden die verschiedenen Arten von Scanvorgängen behandeln, die in Aurora DSQL verfügbar sind, und Ihnen helfen, die Kosten für die Ausführung Ihrer Abfragen zu verstehen.
EXPLAIN-Pläne FÜR PostgreSQL UND Aurora DSQL
Aurora DSQL basiert auf der PostgreSQL-Datenbank und teilt die meisten Planstrukturen mit PostgreSQL, weist jedoch wichtige architektonische Unterschiede auf, die sich auf die Ausführung und Optimierung von Abfragen auswirken:
| Feature | PostgreSQL | Aurora DSQL |
|---|---|---|
|
Datenspeicherung |
Heap-Speicher |
Kein Heap, alle Zeilen werden durch einen eindeutigen Bezeichner indexiert |
|
Primärschlüssel |
Der Primärschlüsselindex ist von den Tabellendaten getrennt |
Der Primärschlüsselindex ist die Tabelle mit allen zusätzlichen Spalten als INCLUDE-Spalten |
|
Sekundäre Indexe |
Standard-Sekundärindizes |
Funktioniert genauso wie PostgreSQL, mit der Möglichkeit, auch Nicht-Schlüsselspalten einzubeziehen |
|
Filterfunktionen |
Indexzustand, Heap-Filter |
Indexbedingung, Speicherfilter, Abfrageprozessor-Filter |
|
Scan-Typen |
Sequentieller Scan, Indexscan, Nur-Index-Scan |
Vollständiger Scan, Nur-Index-Scan, Index-Scan |
|
Ausführung der Abfrage |
Lokal in der Datenbank |
Verteilt (Rechenleistung und Speicher sind getrennt) |
Aurora DSQL speichert Tabellendaten direkt in der Reihenfolge der Primärschlüssel und nicht in einem separaten Heap. Jede Zeile wird durch einen eindeutigen Schlüssel identifiziert, in der Regel durch den Primärschlüssel, wodurch die Datenbank Suchvorgänge effizienter optimieren kann. Der architektonische Unterschied erklärt, warum Aurora DSQL in Fällen, in denen PostgreSQL möglicherweise einen sequentiellen Scan wählt, häufig Index-Only-Scans verwendet.
Ein weiterer wichtiger Unterschied besteht darin, dass Aurora DSQL die Datenverarbeitung vom Speicher trennt, sodass Filter zu einem früheren Zeitpunkt des Ausführungspfads angewendet werden können, um Datenbewegungen zu reduzieren und die Leistung zu verbessern.
Weitere Informationen zur Verwendung von EXPLAIN-Plänen mit PostgreSQL finden Sie in der PostgreSQL EXPLAIN-Dokumentation.
Die wichtigsten Elemente der Aurora DSQL EXPLAIN-Pläne
Aurora DSQL EXPLAIN-Pläne enthalten detaillierte Informationen darüber, wie Abfragen ausgeführt werden, einschließlich der Stelle, an der gefiltert wird und welche Spalten aus dem Speicher abgerufen werden. Wenn Sie diese Ausgabe verstehen, können Sie die Abfrageleistung optimieren.
- Index Cond
Bedingungen, die zum Navigieren im Index verwendet werden. Die effizienteste Filterung, die die Anzahl der gescannten Daten reduziert. In Aurora DSQL können Indexbedingungen auf mehrere Ebenen des Ausführungsplans angewendet werden.
- Projektionen
Aus dem Speicher abgerufene Spalten. Weniger Prognosen bedeuten eine bessere Leistung.
- Speicherfilter
Auf Speicherebene geltende Bedingungen. Effizienter als Abfrageprozessor-Filter.
- Prozessor-Filter abfragen
-
Bedingungen, die auf der Ebene des Abfrageprozessors angewendet werden. Erfordert die Übertragung aller Daten vor dem Filtern, was zu einem höheren Datenverschiebungs- und Verarbeitungsaufwand führt.
Filter in Aurora DSQL
Aurora DSQL trennt Rechenleistung vom Speicher, was bedeutet, dass der Punkt, an dem Filter während der Abfrageausführung angewendet werden, erhebliche Auswirkungen auf die Leistung hat. Filter, die angewendet werden, bevor große Datenmengen übertragen werden, reduzieren die Latenz und verbessern die Effizienz. Je früher ein Filter angewendet wird, desto weniger Daten müssen verarbeitet, verschoben und gescannt werden, was zu schnelleren Abfragen führt.
Aurora DSQL kann Filter in mehreren Phasen des Abfragepfads anwenden. Das Verständnis dieser Phasen ist entscheidend für die Interpretation von Abfrageplänen und die Optimierung der Leistung.
| Level | Typ des Filters | Description |
|---|---|---|
| 1 | Zustand indizieren |
Wird beim Scannen des Indexes angewendet. Schränkt ein, wie viele Daten aus dem Speicher gelesen werden, und reduziert die Anzahl der Daten, die an die Rechenebene gesendet werden. |
| 2 | Speicherfilter | Wird angewendet, nachdem Daten aus dem Speicher gelesen, aber bevor sie zur Berechnung gesendet werden. Ein Beispiel hierfür ist ein Filter für eine Include-Spalte eines Indexes. Reduziert die Datenübertragung, aber nicht die gelesene Menge. |
| 3 | Prozessor-Filter abfragen | Wird angewendet, nachdem die Daten die Berechnungsebene erreicht haben. Alle Daten müssen zuerst übertragen werden, was die Latenz und die Kosten erhöht. Derzeit kann Aurora DSQL nicht alle Filter- und Projektionsvorgänge auf dem Speicher ausführen, sodass bei einigen Abfragen möglicherweise auf diese Art der Filterung zurückgegriffen werden muss. |
