Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Unioni a ciclo annidato in batch nei piani Aurora DSQL EXPLAIN
Quando una query unisce un piccolo input esterno a un input interno che Aurora DSQL può scansionare in modo efficiente dallo storage, Aurora DSQL può scegliere un piano. `Nested Loop (Batched Join)` Questo tipo di join riduce i round trip tra i livelli di elaborazione e storage raggruppando più righe esterne prima di sondare il lato interno.
Un ciclo annidato standard elabora una riga esterna alla volta ed esegue nuovamente la scansione interna per ogni riga. Un join a ciclo annidato in batch raccoglie un batch di righe esterne, crea il lavoro di scansione interno per l'intero batch e quindi unisce le righe interne restituite alle righe esterne corrispondenti.
## Come funzionano i join a ciclo annidato in batch
1. Aurora DSQL legge un batch di righe dal lato esterno del join.
1. Se il lato interno è un `Index Scan` or `Index Only Scan` con un `Index Cond` parametro sul lato esterno, Aurora DSQL associa la condizione per ogni riga esterna e combina le chiavi di scansione dell'indice risultanti in un'unica scansione interna in batch. Altri predicati di join non guidano la scansione interna.
1. Un `Index Scan` o `Index Only Scan` senza un parametro esterno si comporta come un or. `Index Cond` `Full Scan` `Sequential Scan` Aurora DSQL non ha chiavi di scansione dell'indice parametrizzate da combinare ed esegue una scansione interna per batch esterno anziché una scansione interna per riga esterna.
1. Aurora DSQL trasmette in streaming le righe dal lato interno non appena arrivano per il batch. Non materializza l'intero risultato interno del batch prima dell'unione.
1. Quando l'`Index Scan`or interno `Index Only Scan` ha un parametro esterno`Index Cond`, Aurora DSQL utilizza il `Recheck Cond` per far corrispondere ogni riga interna restituita alle righe esterne applicabili nel batch. Aurora DSQL applica quindi tutti i predicati di join rimanenti. Senza un parametro esterno`Index Cond`, Aurora DSQL applica direttamente i predicati di join poiché confronta ogni riga interna trasmessa in streaming con il batch esterno.
1. Per i join left e anti join, Aurora DSQL tiene traccia delle righe esterne che corrispondono ed emette le righe non corrispondenti al termine della scansione interna del batch.
Questo approccio è particolarmente utile quando il lato interno è una scansione dell'indice con parametri`Index Cond`, perché i tasti di scansione combinati forniscono un accesso mirato allo storage per l'intero batch esterno.
## Quando Aurora DSQL utilizza questo join
Aurora DSQL considera i join a ciclo annidato in batch quando il lato interno del join è un nodo di scansione fisico, vale a dire un,,, o `Index Scan` `Index Only Scan` `Full Scan``Sequential Scan`, e si prevede che il batch costi meno rispetto all'esecuzione della scansione interna per ogni riga esterna. In pratica, i maggiori vantaggi derivano in genere da un input esterno più piccolo e da una scansione dell'indice interno con un parametro sul lato esterno. `Index Cond`
Se un'altra forma di piano è più economica, ad esempio un hash join o un merge join, Aurora DSQL sceglie quel piano. Per confrontare le forme del piano durante l'ottimizzazione, puoi disabilitare i join a ciclo annidato in batch per la sessione corrente:
```
SET dsql.enable_batched_nestloop = off;
```
## Come leggere l'output dei join a ciclo annidato in batch
La seguente query utilizza l'esempio `transaction` e `account` le tabelle di[Leggere i piani Aurora DSQL EXPLAIN](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;
```
Un piano EXPLAIN può includere un output simile al seguente:
```
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)`
Mostra che Aurora DSQL sta raggruppando le righe esterne prima di sondare il lato interno del join.
`Index Cond`
Mostra il predicato utilizzato per sondare il lato interno del batch corrente. Quando il lato interno è un `Index Scan` or`Index Only Scan`, questo predicato spesso fa riferimento a colonne dal lato esterno del join.
`Filter`
Mostra una condizione applicata al risultato del join. In questo esempio, la `WHERE (a.status = 'active' OR a.customer_id IS NULL)` condizione viene visualizzata qui. In base alla semantica SQL left join standard, questa condizione non può essere inserita nella scansione interna perché così facendo cambierebbero i risultati della query. Aurora DSQL la visualizza come filtro sul nodo join. Al contrario, la condizione on `t.transaction_date` fa riferimento solo alla tabella esterna, quindi appare sotto la scansione fisica esterna.
`Join Type`
Mostra la semantica di join per il join in batch, ad esempio`Left`,, o. `Semi` `Anti`
`Recheck Cond`
Appare solo quando il lato interno è un `Index Scan` o `Index Only Scan` con almeno un `Index Cond` parametro sul lato esterno del join. Per ogni riga interna restituita, Aurora DSQL esegue il ricontrollo su ogni riga esterna del batch per determinare quali righe esterne hanno prodotto quella sonda e devono unirsi a quella riga interna.
`Join Filter`
Mostra i predicati di join che Aurora DSQL valuta dopo aver confrontato una riga interna con le righe esterne candidate del batch. Questi predicati influiscono sulle coppie di righe che si uniscono, ma non guidano la sonda di archiviazione come invece avviene. `Index Cond`
Un nodo di ordinamento precedente
Può apparire quando l'interrogazione richiede un output ordinato. I join a ciclo nidificato in batch non mantengono le stesse garanzie di ordine di output di un ciclo nidificato standard, quindi Aurora DSQL può aggiungere un ordinamento esplicito prima di restituire il set di risultati finale.