嵌套子查询常生成低效嵌套循环连接，因优化器在内层缺索引、行数不可控或外层未筛选时被迫退化为“每行查一次”；需同步确保连接列索引、控制顺序并处理null语义。
为什么嵌套子查询总生成低效的嵌套循环连接
SQL Server 把 WHERE col IN (SELECT ...) 或 EXISTS (SELECT ...) 这类写法，常默认转成嵌套循环连接（Nested Loops），但不是因为它“想用”，而是因为优化器没看到更优路径——尤其当内层子查询缺少索引、返回行数不可控、或外层驱动表未加筛选时，它只能退化成“每行查一次”的 NL。这不是配置问题，是语义+索引双重缺失导致的执行计划僵化。
- 驱动表若返回 5000 行，而内层
orders没有user_id索引，就会触发 5000 次全表扫描 -
IN子查询中带ORDER BY或LIMIT/TOP（无对应索引）会强制物化临时结果，进一步阻断并行与连接重排 - 统计信息过期时，优化器误判内层结果集大小，把本该走哈希连接的场景硬塞进 NL 分支
用 JOIN 替代 IN/EXISTS 时必须同步处理的三件事
光把 WHERE id IN (SELECT id FROM b) 改成 INNER JOIN b ON a.id = b.id 不够，漏掉任一环节，NL 依然照旧。
- 确保连接列两边都有索引：
a.id和b.id都得是索引键（单列或复合索引前导列），否则 SQL Server 仍可能选 NL + Table Scan - 显式控制连接顺序：用
OPTION (FORCE ORDER)临时验证是否因顺序错乱导致 NL 被迫成为唯一选择；长期方案是加覆盖索引，让优化器有底气选哈希或合并 - 检查 NULL 行影响：
IN遇到子查询返回NULL整体判为 UNKNOWN，JOIN则直接过滤掉，行为不等价——需补OR b.id IS NULL或提前WHERE b.id IS NOT NULL
哪些嵌套子查询不该硬改成 JOIN
不是所有嵌套都适合扁平化。盲目替换反而引入语义偏差或更大开销。
-
SELECT name, (SELECT COUNT(*) FROM logs l WHERE l.user_id = u.id AND l.ts > DATEADD(day, -7, GETDATE()))：这种带时间窗口的聚合，改 JOIN 会爆炸性膨胀中间结果集；应改用窗口函数或 CTE 预聚合 -
WHERE status IN (SELECT value FROM STRING_SPLIT(@status_list, ','))：参数化列表，本质是动态枚举，JOIN 无法复用执行计划；保持IN，但确保STRING_SPLIT输出被强制物化（加OPTION (RECOMPILE)） - 子查询含非确定性函数（如
NEWID(),GETDATE()）：JOIN 会多次调用，而标量子查询至少保证“每行一次”；这类应抽离为变量或用 APPLY 控制执行粒度
真正让嵌套循环变快的底层动作
与其纠结“怎么避免 NL”，不如接受它在某些场景下就是最优解——关键是你得让它跑得轻、找得准。
- 给被驱动表建窄索引：比如
orders(user_id) INCLUDE (order_date, status)，避免 NL 执行时反复回表取字段 - 限制驱动表数据量：在 JOIN 前加前置筛选，如
FROM users u WHERE u.is_active = 1，把驱动行数从 10 万压到 2000，NL 性能直接提升 50 倍 - 确认统计信息新鲜度：
UPDATE STATISTICS orders WITH FULLSCAN，尤其当子查询涉及大表且数据分布倾斜时，过期统计会让优化器高估 NL 成本，不敢换哈希
最常被跳过的动作是验证索引是否真被用上——执行计划里看 Index Seek 的 Predicate 是否包含你期望的字段，而不是只扫一眼“有没有索引图标”。
