Den nested loop join, även kallad nested iteration, använder en join-inmatning som den yttre inmatningstabellen (visas som den översta inmatningen i den grafiska exekveringsplanen, se figur 1 nedan) och den andra inmatningen som den inre inmatningstabellen. Den yttre slingan använder den yttre inmatningstabellen rad för rad. Den inre slingan, som utförs för varje yttre rad, söker efter matchande rader i den inre inmatningstabellen. Nedanstående listning är ett exempel som producerar en 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: Detta finns tillgängligt för nedladdning på wrox.com.
Figur 1. Exempel på en exekveringsplan för en inbäddad loop join
En inbäddad loop join är särskilt effektiv om den yttre indata är liten och den inre indata är sorterad och stor. I många små transaktioner, t.ex. sådana som endast påverkar en liten uppsättning rader, är indexerade nested loop joins överlägsna både merge joins och hash joins. I stora frågor är dock nested loop joins ofta inte det optimala valet. Närvaron av en operatör för en nested loop join i exekveringsplanen indikerar naturligtvis inte om det är en effektiv plan. En inbäddad loop join är standardalgoritmen. Det betyder inte att det är den första algoritmen som används (det skulle vara en hash-hopning i minnet), utan att den alltid kan tillämpas om en annan algoritm uppfyller de specifika kriterierna. Till exempel måste algoritmen ”requires join” vara equijoin. (Joinvillkoret baseras på likhetsoperatorn.)
I exempelfrågan utförs en klustrad indexsökning på den yttre tabellen Customer där CustomerID är 10 eller 12, och för varje CustomerID utförs en indexsökning på den inre tabellen SalesOrderHeader. Därför söks index IX_SalesOrderHeader_CustomerID två gånger (en gång för CustomerID 10 och en gång för CustomerID 12) i tabellen SalesOrderHeader.