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.
Mit Aurora DSQL EXPLAIN-Plänen arbeiten
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 Aurora DSQL EXPLAIN-Pläne und heben die Ähnlichkeiten und Unterschiede im Vergleich zu PostgreSQL hervor. Wir behandeln die verschiedenen Arten von Scanvorgängen, die in Aurora DSQL verfügbar sind, und helfen Ihnen, die Kosten für die Ausführung Ihrer Abfragen zu verstehen.
PostgreSQL VS Aurora DSQL EXPLAIN-Pläne
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 sind 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, Nichtschlüsselspalten einzubeziehen |
|
Filterfunktionen |
Indexbedingung, Heap-Filter |
Indexbedingung, Speicherfilter, Abfrageprozessorfilter |
|
Scan-Typen |
Sequentieller Scan, Indexscan, Nur Indexscan |
Vollständiger Scan, Nur Indexscan, Indexscan |
|
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 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 Rechenleistung vom Speicher trennt, sodass Filter früher im Ausführungspfad 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
Schlüsselelemente der Aurora DSQL EXPLAIN-Pläne
Aurora DSQL EXPLAIN-Pläne bieten detaillierte Informationen darüber, wie Abfragen ausgeführt werden, einschließlich der Orte, an denen 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 für die Navigation im Index verwendet werden. Effizienteste Filterung, die die Anzahl der gescannten Daten reduziert. In Aurora DSQL können Indexbedingungen auf mehreren Ebenen des Ausführungsplans angewendet werden.
- Projektionen
Aus dem Speicher abgerufene Spalten. Weniger Prognosen bedeuten bessere Leistung.
- Speicherfilter
Auf Speicherebene angewandte Bedingungen. Effizienter als Filter für Abfrageprozessoren.
- Prozessorfilter abfragen
-
Auf der Ebene des Abfrageprozessors angewandte Bedingungen. 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 vor der Übertragung großer Datenmengen angewendet 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 | Indexbedingung |
Wird beim Scannen des Index angewendet. Beschränkt, wie viele Daten aus dem Speicher gelesen werden, und reduziert die Anzahl der an die Rechenebene gesendeten Daten. |
| 2 | Speicherfilter | Wird angewendet, nachdem Daten aus dem Speicher gelesen wurden, aber bevor sie an den Computer gesendet werden. Ein Beispiel hierfür ist ein Filter in einer Include-Spalte eines Indexes. Reduziert die Datenübertragung, aber nicht die Menge, die gelesen wird. |
| 3 | Prozessorfilter abfragen | Wird angewendet, nachdem Daten die Rechenschicht 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 im Speicher durchführen, sodass einige Abfragen möglicherweise gezwungen sind, auf diese Art der Filterung zurückzugreifen. |
