De nested loop join, ook wel nested iteration genoemd, gebruikt een join invoer als de buitenste invoertabel (weergegeven als de bovenste invoer in het grafische uitvoerplan; zie afbeelding 1 hieronder) en de andere invoer als de binnenste invoertabel. De buitenste lus verbruikt de buitenste invoertabel rij per rij. De binnenste lus, die voor elke buitenste rij wordt uitgevoerd, zoekt naar overeenkomende rijen in de binnenste invoertabel. Onderstaande listing is een voorbeeld van een “nested loop join”.
--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: Deze is beschikbaar voor download op wrox.com.
Figuur 1.
Een geneste lusverbinding is vooral effectief als de buitenste invoer klein is en de binnenste invoer gesorteerd en groot. In veel kleine transacties, zoals die met slechts een kleine set rijen, zijn geïndexeerde “nested loop joins” superieur aan zowel merge joins als hash joins. Bij grote queries zijn geneste loop joins echter vaak niet de optimale keuze. De aanwezigheid van een geneste loop join operator in het uitvoeringsplan geeft natuurlijk niet aan of het een efficiënt plan is. Een geneste lusverbinding is het standaard algoritme. Dit betekent niet dat het het eerste algoritme is dat wordt gebruikt (dat zou de in-memory hash join zijn), maar dat het altijd kan worden toegepast als een ander algoritme wel aan de specifieke criteria voldoet. Bijvoorbeeld, het “vereist join” algoritme moet equijoin zijn. (De join conditie is gebaseerd op de equality operator.)
In de voorbeeldquery wordt een geclusterde index gezocht op de buitentabel Customer waar CustomerID 10 of 12 is, en voor elke CustomerID wordt een index gezocht op de binnentabel SalesOrderHeader. Daarom wordt index IX_SalesOrderHeader_CustomerID twee keer gezocht (een keer voor CustomerID 10 en een keer voor CustomerID 12) op de tabel SalesOrderHeader.