View a markdown version of this page

Jointures en boucle imbriquée par lots dans les plans Aurora DSQL EXPLAIN - Amazon Aurora DSQL

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Jointures en boucle imbriquée par lots dans les plans Aurora DSQL EXPLAIN

Lorsqu'une requête joint une petite entrée externe à une entrée interne qu'Aurora DSQL peut analyser efficacement depuis le stockage, Aurora DSQL peut choisir un Nested Loop (Batched Join) plan. Ce type de jointure réduit les allers-retours entre les couches de calcul et de stockage en regroupant plusieurs rangées extérieures avant de sonder la face intérieure.

Une boucle imbriquée standard traite une ligne extérieure à la fois et exécute à nouveau le scan interne pour chaque ligne. Une jointure en boucle imbriquée par lots collecte un lot de lignes extérieures, crée le travail de numérisation interne pour l'ensemble du lot, puis relie les lignes intérieures renvoyées aux lignes extérieures correspondantes.

Comment fonctionnent les jointures en boucle imbriquée par lots

  1. Aurora DSQL lit un lot de lignes depuis le côté extérieur de la jointure.

  2. Si la face interne est une Index Scan ou si une Index Only Scan valeur est Index Cond paramétrée sur la face externe, Aurora DSQL lie la condition pour chaque ligne extérieure et combine les clés de scan d'index résultantes en une seule analyse interne par lots. Les autres prédicats de jointure ne pilotent pas le scan interne.

  3. Un Index Scan ou Index Only Scan sans paramétrage externe se Index Cond comporte comme un ou. Full Scan Sequential Scan Aurora DSQL ne dispose d'aucune clé d'analyse d'index paramétrée à combiner et exécute une analyse interne par lot externe au lieu d'une analyse interne par ligne externe.

  4. Aurora DSQL diffuse les lignes depuis la face interne au fur et à mesure qu'elles arrivent pour le lot. Il ne matérialise pas l'intégralité du résultat interne du lot avant de le joindre.

  5. Lorsque la ligne intérieure Index Scan ou extérieure Index Only Scan est paramétréeIndex Cond, Aurora DSQL l'utilise Recheck Cond pour faire correspondre chaque ligne intérieure renvoyée aux lignes extérieures applicables du lot. Aurora DSQL applique ensuite tous les prédicats de jointure restants. Sans paramétrage externeIndex Cond, Aurora DSQL applique les prédicats de jointure directement en faisant correspondre chaque ligne interne diffusée au lot externe.

  6. Pour les jointures gauches et antijointures, Aurora DSQL suit les lignes extérieures qui correspondent et émet des lignes sans correspondance une fois l'analyse interne du lot terminée.

Cette approche est particulièrement utile lorsque la face interne est un scan d'index paramétréIndex Cond, car les touches de numérisation combinées fournissent un accès au stockage ciblé pour l'ensemble du lot extérieur.

Quand Aurora DSQL utilise cette jointure

Aurora DSQL prend en compte les jointures en boucle imbriquée par lots lorsque la face interne de la jointure est un nœud de scan physique, ce qui signifie unIndex Scan,, ou Index Only Scan Full ScanSequential Scan, et le traitement par lots devrait coûter moins cher que l'exécution du scan interne pour chaque ligne extérieure. Dans la pratique, le plus grand avantage provient généralement d'une entrée externe plus petite et d'un scan de l'index interne avec un Index Cond paramétrage sur le côté extérieur.

Si une autre forme de plan est moins chère, telle qu'une jointure par hachage ou une jointure par fusion, Aurora DSQL choisit ce plan à la place. Pour comparer les formes de plan pendant le réglage, vous pouvez désactiver les jointures en boucle imbriquée par lots pour la session en cours :

SET dsql.enable_batched_nestloop = off;

Comment lire la sortie de jointure en boucle imbriquée par lots

La requête suivante utilise l'exemple transaction et account les tableaux de Lire les plans Aurora SQL EXPLAIN :

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 plan EXPLAIN peut inclure des résultats similaires aux suivants :

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)

Montre qu'Aurora DSQL regroupe les lignes extérieures par lots avant de sonder la face interne de la jointure.

Index Cond

Indique le prédicat utilisé pour sonder la face interne du lot actuel. Lorsque le côté intérieur est un Index Scan ouIndex Only Scan, ce prédicat fait souvent référence à des colonnes situées du côté extérieur de la jointure.

Filter

Affiche une condition appliquée au résultat de la jointure. Dans cet exemple, la WHERE (a.status = 'active' OR a.customer_id IS NULL) condition apparaît ici. Selon la sémantique SQL standard de jointure gauche, cette condition ne peut pas être intégrée à l'analyse interne car cela modifierait les résultats de la requête. Aurora DSQL l'affiche sous forme de filtre sur le nœud de jointure. En revanche, la condition sur ne t.transaction_date fait référence qu'au tableau externe, de sorte qu'elle apparaît sous le scan physique externe.

Join Type

Affiche la sémantique de jointure pour la jointure par lots, telle queLeft, Semi ou. Anti

Recheck Cond

Apparaît uniquement lorsque le côté intérieur est un Index Scan ou si Index Only Scan au moins un de ces éléments est Index Cond paramétré sur le côté extérieur de la jointure. Pour chaque ligne intérieure renvoyée, Aurora DSQL effectue une nouvelle vérification sur chaque ligne extérieure du lot afin de déterminer quelles lignes extérieures ont produit cette sonde et doivent être jointes à cette ligne intérieure.

Join Filter

Affiche les prédicats de jointure qu'Aurora DSQL évalue après avoir fait correspondre une ligne intérieure aux lignes extérieures candidates du lot. Ces prédicats affectent les paires de lignes qui se rejoignent, mais ils ne pilotent pas la sonde de stockage de la même manièreIndex Cond.

Un nœud de tri précédent

Peut apparaître lorsque la requête nécessite une sortie ordonnée. Les jointures en boucle imbriquée par lots ne préservent pas les mêmes garanties d'ordre de sortie qu'une boucle imbriquée standard. Aurora DSQL peut donc ajouter un tri explicite avant de renvoyer le jeu de résultats final.