NestedLoopsJoin berechnet den Join seiner rechten und linken Seite, indem er die rechte Seite vollständig nach jeder Zeile der linken Seite durchsucht. (Die syntaktische Reihenfolge der Tabellen in der Abfrage ist ohne Bedeutung, da der Optimierer die geeignete Join-Reihenfolge für jeden Block in der Anforderung auswählt.)

Der Optimierer wählt möglicherweise NestedLoopsJoin, wenn die Join-Bedingung keine Gleichheitsbedingung enthält oder wenn die Anweisung mit dem Optimierungsziel "erste Zeile" optimiert wurde (d.h. wenn die Option "optimization_goal" auf "erste Zeile" gesetzt ist, oder wenn FASTFIRSTROW als Tabellen-Hint in der FROM-Klausel angegeben ist).

Da NestedLoopsJoin die rechte Seite mehrere Male liest, ist er für die rechte Seite sehr kostenintensiv. Wenn die rechte Seite ein Index-Scan oder eine kleine Tabelle ist, kann die rechte Seite wahrscheinlich unter Verwendung der im Cache abgelegten Seiten berechnet werden. Wenn es sich aber bei der rechten Seite um einen sequenziellen Table-Scan oder einen Index-Scan handelt, der viele Zeilen vergleicht, dann muss die rechte Seite viele Male von der Festplatte gelesen werden. Daher ist NestedLoopsJoin nicht so effizient wie andere Join-Methoden. NestedLoopsJoin kann jedoch die erste übereinstimmende Zeile schneller zurückgeben als Join-Methoden, die erst ein vollständiges Ergebnis berechnen müssen, bevor sie Inhalte zurückgeben.

NestedLoopsJoin ist der einzige Join-Algorithmus, der empfindliche Semantik für Abfragen mit Joins bietet. Das bedeutet, dass empfindliche Cursors für Joins nur mit NestedLoopsJoin ausgeführt werden können.

 Siehe auch