La jointure en boucle imbriquée, également appelée itération imbriquée, utilise une entrée de jointure comme table d’entrée externe (représentée comme l’entrée supérieure dans le plan d’exécution graphique ; voir la figure 1 ci-dessous) et l’autre entrée comme table d’entrée interne. La boucle externe consomme la table d’entrée externe ligne par ligne. La boucle interne, exécutée pour chaque ligne externe, recherche les lignes correspondantes dans le tableau d’entrée interne. Le listing ci-dessous est un exemple qui produit une jointure en boucle imbriquée.
--Nested Loop Join SELECT C.CustomerID, c.TerritoryID FROM Sales.SalesOrderHeader oh JOIN Sales.Customer c ON c.CustomerID = oh.CustomerID WHERE c.CustomerID IN (10,12) GROUP BY C.CustomerID, c.TerritoryID
Note : Ceci est disponible en téléchargement sur wrox.com.
Figure 1. Exemple de plan d’exécution pour une jointure en boucle imbriquée
Une jointure en boucle imbriquée est particulièrement efficace si l’entrée externe est petite et l’entrée interne est triée et grande. Dans de nombreuses petites opérations, comme celles qui n’affectent qu’un petit ensemble de lignes, les jointures en boucle imbriquée indexées sont supérieures aux jointures de fusion et aux jointures de hachage. Dans les grandes requêtes, cependant, les jointures en boucle imbriquée ne sont souvent pas le choix optimal. Bien entendu, la présence d’un opérateur de jointure en boucle imbriquée dans le plan d’exécution n’indique pas s’il s’agit d’un plan efficace. La jonction de boucles imbriquées est l’algorithme par défaut. Cela ne signifie pas que c’est le premier algorithme utilisé (ce serait la jointure de hachage en mémoire), mais qu’il peut toujours être appliqué si un autre algorithme correspond aux critères spécifiques. Par exemple, l’algorithme « exigeant la jointure » doit être equijoin. (La condition de jointure est basée sur l’opérateur d’égalité.)
Dans la requête d’exemple, une recherche d’index en cluster est effectuée sur la table externe Customer où CustomerID est 10 ou 12, et pour chaque CustomerID, une recherche d’index est effectuée sur la table interne SalesOrderHeader. Par conséquent, l’index IX_SalesOrderHeader_CustomerID est recherché deux fois (une fois pour le CustomerID 10 et une fois pour le CustomerID 12) sur la table SalesOrderHeader.