Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Gabungan loop bersarang berkelompok dalam rencana Aurora DSQL EXPLAIN
Ketika kueri menggabungkan input luar kecil ke input dalam yang dapat dipindai Aurora DSQL secara efisien dari penyimpanan, Aurora DSQL dapat memilih `Nested Loop (Batched Join)` paket. Jenis gabungan ini mengurangi perjalanan pulang pergi antara lapisan komputasi dan penyimpanan dengan mengelompokkan beberapa baris luar bersama-sama sebelum menyelidiki sisi dalam.
Loop bersarang standar memproses satu baris luar pada satu waktu dan menjalankan pemindaian dalam lagi untuk setiap baris. Gabungan loop bersarang berkelompok mengumpulkan kumpulan baris luar, membangun pekerjaan pemindaian dalam untuk seluruh batch, dan kemudian menggabungkan baris dalam yang dikembalikan kembali ke baris luar yang cocok.
## Cara kerja gabungan batched nested-loop
1. Aurora DSQL membaca kumpulan baris dari sisi luar gabungan.
1. Jika sisi dalam adalah `Index Scan` atau `Index Only Scan` dengan `Index Cond` parameter di sisi luar, Aurora DSQL mengikat kondisi untuk setiap baris luar dan menggabungkan kunci pemindaian indeks yang dihasilkan menjadi satu pemindaian dalam berkelompok. Predikat gabungan lainnya tidak mendorong pemindaian batin.
1. Sebuah `Index Scan` atau `Index Only Scan` tanpa parameter luar ber `Index Cond` perilaku seperti atau. `Full Scan` `Sequential Scan` Aurora DSQL tidak memiliki kunci pemindaian indeks berparameter untuk menggabungkan dan menjalankan satu pemindaian dalam per batch luar, bukan satu pemindaian dalam per baris luar.
1. Aurora DSQL mengalirkan baris dari sisi dalam saat tiba untuk batch. Itu tidak mewujudkan seluruh hasil batin untuk batch sebelum bergabung.
1. Ketika bagian dalam `Index Scan` atau `Index Only Scan` memiliki parameter luar`Index Cond`, Aurora DSQL menggunakan `Recheck Cond` untuk mencocokkan setiap baris dalam yang dikembalikan kembali ke baris luar yang berlaku dalam batch. Aurora DSQL kemudian menerapkan predikat gabungan yang tersisa. Tanpa parameter luar`Index Cond`, Aurora DSQL menerapkan predikat gabungan secara langsung karena cocok dengan setiap baris dalam yang dialirkan dengan batch luar.
1. Untuk gabungan kiri dan anti, Aurora DSQL melacak baris luar mana yang cocok dan memancarkan baris yang tidak tertandingi setelah pemindaian dalam untuk batch selesai.
Pendekatan ini paling berguna ketika sisi dalam adalah pemindaian indeks dengan parameter`Index Cond`, karena kunci pemindaian gabungan menyediakan akses penyimpanan yang ditargetkan untuk seluruh batch luar.
## Saat Aurora DSQL menggunakan gabungan ini
Aurora DSQL mempertimbangkan gabungan loop bersarang batched ketika sisi dalam gabungan adalah simpul pemindaian fisik, yang berarti,`Index Scan`,, atau `Index Only Scan` `Full Scan``Sequential Scan`, dan batching diharapkan lebih murah daripada menjalankan pemindaian dalam untuk setiap baris luar. Dalam praktiknya, manfaat terbesar biasanya berasal dari input luar yang lebih kecil dan pemindaian indeks dalam `Index Cond` dengan parameter di sisi luar.
Jika bentuk paket lain lebih murah, seperti hash join atau merge join, Aurora DSQL memilih paket itu sebagai gantinya. Untuk membandingkan bentuk rencana selama penyetelan, Anda dapat menonaktifkan gabungan batched nested-loop untuk sesi saat ini:
```
SET dsql.enable_batched_nestloop = off;
```
## Cara membaca output gabungan loop bersarang berkelompok
Kueri berikut menggunakan sampel `transaction` dan `account` tabel dari[Membaca Aurora DSQL JELASKAN rencana](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;
```
Rencana EXPLAIN dapat mencakup output yang mirip dengan berikut ini:
```
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)`
Menunjukkan bahwa Aurora DSQL menggabungkan baris luar sebelum menyelidiki sisi dalam gabungan.
`Index Cond`
Menunjukkan predikat yang digunakan untuk menyelidiki sisi dalam untuk batch saat ini. Ketika sisi dalam adalah `Index Scan` atau`Index Only Scan`, predikat ini sering merujuk kolom dari sisi luar gabungan.
`Filter`
Menunjukkan kondisi yang diterapkan pada hasil gabungan. Dalam contoh ini, `WHERE (a.status = 'active' OR a.customer_id IS NULL)` kondisi muncul di sini. Di bawah semantik gabungan kiri SQL standar, kondisi ini tidak dapat didorong ke pemindaian dalam karena hal itu akan mengubah hasil kueri. Aurora DSQL menampilkannya sebagai filter pada node gabungan. Sebaliknya, kondisi pada `t.transaction_date` referensi hanya tabel luar, sehingga muncul di bawah pemindaian fisik luar.
`Join Type`
Menampilkan semantik gabungan untuk gabungan batch, seperti`Left`,, atau. `Semi` `Anti`
`Recheck Cond`
Muncul hanya ketika sisi dalam adalah `Index Scan` atau `Index Only Scan` dengan setidaknya `Index Cond` satu parameter di sisi luar gabungan. Untuk setiap baris dalam yang dikembalikan, Aurora DSQL menjalankan pemeriksaan ulang terhadap setiap baris luar dalam batch untuk menentukan baris luar mana yang menghasilkan probe itu dan harus bergabung dengan baris dalam itu.
`Join Filter`
Menampilkan predikat gabungan yang dievaluasi Aurora DSQL setelah mencocokkan baris dalam kembali ke baris luar kandidat dalam batch. Predikat ini memengaruhi pasangan baris mana yang bergabung, tetapi mereka tidak mendorong probe penyimpanan seperti yang terjadi`Index Cond`.
Node pengurutan sebelumnya
Dapat muncul ketika query membutuhkan output yang dipesan. Gabungan loop bersarang batched tidak mempertahankan jaminan urutan keluaran yang sama dengan loop bersarang standar, sehingga Aurora DSQL dapat menambahkan pengurutan eksplisit sebelum mengembalikan set hasil akhir.