嵌套循环连接（NLJ）仅在驱动侧实际返回行数极少（几十至几百行）且被驱动侧连接列有高效索引时才高效；无索引则退化为全表扫描，代价达O(M×N)；非等值连接是其刚性使用场景，但性能高度依赖索引范围扫描效率。
嵌套循环连接（Nested Loop Join）不是“小表驱动大表”就能随便用的——它真正靠谱的场景，是驱动侧**实际返回行数极少**，且被驱动侧连接列**有高效索引可用**。否则内层每次都要扫全表，O(M × N) 就直接变成性能黑洞。
驱动表结果集必须真小，不是“看起来小”
优化器看的是估算行数，不是 COUNT(*)。比如 WHERE create_time > '2026-01-01' 看似范围窄，但如果统计信息过期或数据倾斜严重，它可能误估成 5000 行——这时即使你手动加 /*+ USE_NL */，实际执行也会慢得离谱。
- 安全阈值通常在几十到几百行以内；上万行基本该换
Hash Join或Sort Merge Join -
EXISTS/IN子查询里用NESTED-LOOP Semi Join是典型场景：驱动侧每行找到第一个匹配就停，短路优势明显 - 带
LIMIT的交互式查询（如分页第 1 页）适合它，因为能流式输出首行，不用等全部连接完成
被驱动表连接列没索引？基本等于放弃 NLJ
没有索引时，Index Nested-Loop Join 退化为 Simple Nested-Loop Join，内层每次都是全表扫描。哪怕驱动侧只返回 10 行，被驱动表有百万行，代价就是 10 × 1,000,000 次 I/O —— 这比 Hash Join 构建一次哈希表还贵。
- 检查执行计划里是否出现
Index Nested-Loop Join，而不是裸的Nested Loops（SQL Server）或没索引提示的Using join buffer（MySQL） - 复合索引要注意最左前缀：如果连接条件是
ON a.x = b.y AND b.z = ?，索引得是(y, z)，只建(z)没用 - 非等值连接（如
BETWEEN、）只能走 NLJ，但此时更依赖索引是否支持范围查找（B-Tree 可以，哈希索引不行）
非等值连接是 NLJ 的刚性使用场景
只要连接条件含 、<code>>、BETWEEN、OVERLAPS 等非等值谓词，Hash Join 和 Sort Merge Join 都无法使用——数据库没得选，只能用嵌套循环。
- 典型例子：
SELECT * FROM events e JOIN periods p ON e.time BETWEEN p.start AND p.end - 此时性能生死线在于：驱动表行数 × 内层索引范围扫描效率。没索引？直接 O(M × N) 暴毙
- PostgreSQL 里可配合
gist或spgist索引加速区间查找；MySQL/SQL Server 则强依赖 B-Tree 上的起始字段有序性
最容易被忽略的一点：NLJ 的“快首行”和“慢总耗时”是一体两面。用户拉到第 10 页时，它可能还在吭哧吭哧循环——而 Hash Join 此时早已把结果缓存在内存里了。别只看 EXPLAIN 里的“启动时间”，得实测真实翻页延迟。
