针对SQL Server中的嵌套循环连接（Nested Loops Join），一个核心结论值得牢记：其性能优劣主要取决于三个关键因素——外表行数、内表索引情况以及统计信息的准确性。只要这三方面配置得当，Loop Join在I/O和CPU资源上的开销便能达到最低水平。相反，若其中任何一环出现偏差，性能便可能急剧下降。

原因并不复杂。Loop Join的执行开销与外表行数呈正比关系，而内表的每次匹配只需执行一次索引查找——前提是存在合适的索引。这也恰好解释了为何小结果集特别适合Loop Join：外表行数少，总查找次数完全处于可控范围。

外表行数越小，Loop Join的I/O放大效应越低

Loop Join的执行机制本质上就是：针对外表的每一行，在内表中进行一次查找。这完全符合两层循环的逻辑——教科书上的描述，SQL Server也是如此实现的。这意味着，如果外表返回10行且内表有索引，则最多执行10次索引查找（seek）；但如果外表返回10万行，即使每次seek只读取2页，总逻辑读也可高达20万页。来看一个实际例子：当TempA（7行）作为外表时，内表TempB（700行）被读取了100次逻辑页；反之，若以TempB作为外表，TempA则会被扫描700次——尽管每页数据量较小，但总读取量仍然急剧上升。

• 外表行数直接决定了循环次数——这是Loop Join无法回避的固定开销
• 内表采用索引查找（seek）还是全表扫描（scan），完全由连接列上是否存在有效索引决定
• 外表行数从100增至1万时，性能往往不是线性衰减，而是呈现阶跃式恶化趋势

内表缺乏索引时，Loop Join性能将迅速恶化

若内表缺少索引，在Loop Join中会引发灾难性后果：外表每返回一行，内表就必须执行一次全表扫描。此时算法复杂度从O(N × log M)直接退化为O(N × M)，与两侧数据量的乘积成正比。试想，外表1000行、内表10万行且无索引时，需要进行1亿次比较——如此庞大的计算量，任何系统都难以承受。

• 审查执行计划，确认内表算子显示的是Index Seek，还是Table Scan或Clustered Index Scan
• 若WHERE条件能将外表过滤至极小（例如WHERE OrderID = 100），其效果往往比直接为内表添加索引更为显著
• 复合索引的列顺序至关重要：当连接条件为ON a.x = b.x时，索引必须以x作为前导列才能被有效利用

统计信息不准会误导优化器错误选择驱动表

SQL Server完全依赖统计信息来估算外表大小。若未及时执行UPDATE STATISTICS，系统可能将实际仅有5行的外表错误估算为5000行——后果便是优化器放弃Loop Join，转而选择Hash Match连接。Hash Match的内存开销较大，对于小结果集而言，反而会增加不必要的负担。

• 使用DBCC SHOW_STATISTICS('table', 'index')检查Rows与Rows Sampled是否接近
• 在执行计划中对比Estimated Row Count与Actual Row Count，若两者相差10倍以上，则应立即更新统计信息
• 对于频繁变更的小表，可考虑将AUTO_UPDATE_STATISTICS_ASYNC设置为OFF，以避免统计信息更新延迟

这恰恰是问题的核心——真正制约Loop Join性能的，通常并非算法本身，而是外表行数不可控、内表缺少索引以及统计信息过期这三重因素的叠加。只要单独解决其中任何一个环节，便有可能使查询耗时从秒级降至毫秒级。