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.
# Batch-Joins mit verschachtelten Schleifen in Aurora DSQL EXPLAIN-Plänen
Wenn eine Abfrage eine kleine äußere Eingabe mit einer inneren Eingabe verbindet, die Aurora DSQL effizient vom Speicher aus scannen kann, kann Aurora DSQL einen Plan auswählen. `Nested Loop (Batched Join)` Dieser Verbindungstyp reduziert Roundtrips zwischen der Rechen- und der Speicherebene, indem mehrere äußere Zeilen gruppiert werden, bevor die Innenseite untersucht wird.
Eine standardmäßige geschachtelte Schleife verarbeitet jeweils eine äußere Zeile und führt den inneren Scan für jede Zeile erneut durch. Ein Batch-Join mit verschachtelten Schleifen sammelt einen Stapel äußerer Zeilen, erstellt den inneren Scanvorgang für den gesamten Stapel und verbindet dann die zurückgegebenen inneren Zeilen wieder mit den entsprechenden äußeren Zeilen.
## So funktionieren Batch-Joins mit verschachtelten Schleifen
1. Aurora DSQL liest einen Stapel von Zeilen von der Außenseite des Joins.
1. Wenn es sich bei der Innenseite um ein `Index Scan` oder `Index Only Scan` mit einem `Index Cond` Parameter auf der Außenseite handelt, bindet Aurora DSQL die Bedingung für jede äußere Zeile und kombiniert die resultierenden Index-Scan-Schlüssel zu einem Batch-internen Scan. Andere Join-Prädikate steuern den inneren Scan nicht.
1. Ein `Index Scan` oder `Index Only Scan` ohne ein äußeres Parametrierfeld verhält sich `Index Cond` wie ein oder. `Full Scan` `Sequential Scan` Aurora DSQL hat keine parametrisierten Index-Scan-Schlüssel zum Kombinieren und führt einen inneren Scan pro äußerem Stapel aus, anstatt einen inneren Scan pro äußerer Zeile.
1. Aurora DSQL streamt Zeilen von der Innenseite, sobald sie für den Batch ankommen. Es materialisiert nicht das gesamte innere Ergebnis für den Stapel, bevor er zusammengefügt wird.
1. Wenn die innere `Index Scan` oder die äußere Zeile einen äußeren Parameter `Index Only Scan` hat, verwendet Aurora DSQL den`Index Cond`, `Recheck Cond` um jede zurückgegebene innere Zeile wieder den entsprechenden äußeren Zeilen im Stapel zuzuordnen. Aurora DSQL wendet dann alle verbleibenden Join-Prädikate an. Ohne eine äußere Parametrisierung wendet Aurora DSQL die Join-Prädikate direkt an`Index Cond`, da jede gestreamte innere Zeile mit dem äußeren Batch verglichen wird.
1. Bei Links- und Anti-Joins verfolgt Aurora DSQL, welche äußeren Zeilen übereinstimmen, und gibt nach Abschluss des inneren Scans für den Batch Zeilen aus, die nicht übereinstimmen.
Dieser Ansatz ist am nützlichsten, wenn es sich bei der Innenseite um einen Index-Scan mit einem parametrisierten Code handelt`Index Cond`, da die kombinierten Scan-Schlüssel einen gezielten Speicherzugriff für den gesamten äußeren Batch ermöglichen.
## Wenn Aurora DSQL diesen Join verwendet
Aurora DSQL betrachtet Batch-Joins in verschachtelten Schleifen, wenn es sich bei der Innenseite des Joins um einen physischen Scan-Knoten handelt, was bedeutet`Index Scan`, dass ein`Index Only Scan`,`Full Scan`, oder`Sequential Scan`, und das Batching voraussichtlich weniger kostet als das Ausführen des inneren Scans für jede äußere Zeile. In der Praxis ergibt sich der größte Vorteil in der Regel aus einer kleineren äußeren Eingabe und einem inneren Index-Scan mit einem `Index Cond` parametrisierten Scan auf der Außenseite.
Wenn eine andere Planform günstiger ist, wie z. B. ein Hash-Join oder Merge-Join, wählt Aurora DSQL stattdessen diesen Plan. Um die Planformen während der Optimierung zu vergleichen, können Sie Batch-Joins mit verschachtelten Schleifen für die aktuelle Sitzung deaktivieren:
```
SET dsql.enable_batched_nestloop = off;
```
## Wie liest man die Batch-Ausgabe von Nested-Loop-Joins
Die folgende Abfrage verwendet das Beispiel `transaction` und die `account` Tabellen von[Aurora DSQL EXPLAIN-Pläne lesen](reading-dsql-explain-plans.md):
```
EXPLAIN
SELECT t.account_id, a.balance
FROM transaction t
LEFT JOIN account a
ON t.account_id = a.customer_id
AND a.balance > CASE
WHEN t.description LIKE 'fee%' THEN 0
ELSE 100
END
WHERE t.transaction_date >= '2025-01-01'
AND (a.status = 'active' OR a.customer_id IS NULL)
ORDER BY t.account_id;
```
Ein EXPLAIN-Plan kann Ausgaben enthalten, die der folgenden ähneln:
```
Sort
Sort Key: t.account_id
-> Nested Loop (Batched Join)
Filter: (((status)::text = 'active'::text) OR (customer_id IS NULL))
Join Type: Left
Recheck Cond: (customer_id = t.account_id)
Join Filter: (balance > CASE WHEN (t.description ~~ 'fee%'::text) THEN '0'::numeric ELSE '100'::numeric END)
-> Full Scan (btree-table) on transaction t
-> Storage Scan on transaction t
Filters: (transaction_date >= '2025-01-01 00:00:00'::timestamp without time zone)
-> B-Tree Scan on transaction t
-> Index Only Scan using idx1 on account a
Index Cond: (customer_id = t.account_id)
```
`Nested Loop (Batched Join)`
Zeigt, dass Aurora DSQL die äußeren Zeilen stapelt, bevor die Innenseite des Joins untersucht wird.
`Index Cond`
Zeigt das Prädikat an, das verwendet wird, um die Innenseite des aktuellen Batches zu untersuchen. Wenn es sich bei der Innenseite um ein `Index Scan` Oder handelt`Index Only Scan`, verweist dieses Prädikat häufig auf Spalten von der Außenseite der Verknüpfung.
`Filter`
Zeigt eine Bedingung an, die auf das Ergebnis der Verknüpfung angewendet wurde. In diesem Beispiel wird die `WHERE (a.status = 'active' OR a.customer_id IS NULL)` Bedingung hier angezeigt. Unter der standardmäßigen SQL-Left-Join-Semantik kann diese Bedingung nicht in den inneren Scan übernommen werden, da dies die Abfrageergebnisse ändern würde. Aurora DSQL zeigt es als Filter auf dem Join-Knoten an. Im Gegensatz dazu `t.transaction_date` bezieht sich die Bedingung an nur auf die äußere Tabelle, sodass sie unter dem äußeren physischen Scan erscheint.
`Join Type`
Zeigt die Join-Semantik für die Batch-Verknüpfung an, z. B. `Left``Semi`, oder. `Anti`
`Recheck Cond`
Wird nur angezeigt, wenn es sich bei der Innenseite um eine `Index Scan` oder `Index Only Scan` mit mindestens einem `Index Cond` Parameter auf der Außenseite der Verknüpfung handelt. Für jede zurückgegebene innere Zeile führt Aurora DSQL die erneute Überprüfung für jede äußere Zeile im Batch durch, um zu ermitteln, welche äußeren Zeilen diesen Prüfpunkt erzeugt haben und mit dieser inneren Zeile verknüpft werden sollten.
`Join Filter`
Zeigt Join-Prädikate an, die Aurora DSQL auswertet, nachdem eine innere Zeile den äußeren Kandidatenzeilen im Batch zugeordnet wurde. Diese Prädikate wirken sich darauf aus, welche Zeilenpaare zusammengeführt werden, aber sie steuern den Speichertest nicht in der Weise an, wie das der Fall ist. `Index Cond`
Ein vorangegangener Sortierknoten
Kann erscheinen, wenn die Abfrage eine geordnete Ausgabe benötigt. Bei Batch-Joins mit verschachtelten Schleifen gelten nicht dieselben Garantien für die Ausgabereihenfolge wie bei einer standardmäßigen geschachtelten Schleife. Daher kann Aurora DSQL eine explizite Sortierung hinzufügen, bevor die endgültige Ergebnismenge zurückgegeben wird.