SQL Server因LEFT/FULL OUTER JOIN语法强制左表为驱动表，若其过滤后行数多且右表无索引，Nested Loops会导致性能灾难；需检查索引、统计信息、数据类型一致性及ON子句函数，并可用查询提示禁用NL验证瓶颈。
为什么SQL Server总选Nested Loops，哪怕它很慢
因为LEFT JOIN或FULL OUTER JOIN语法锁死了驱动表顺序——左表必须当外表，优化器没法换边。如果左表实际过滤后仍有几十万行，而右表连接列没索引，就会触发“外表每行 × 右表全扫一遍”的灾难。你看到执行计划里Nested Loops节点上方标着Outer References，下方连着Table Scan或Clustered Index Scan，基本就坐实了。
- 检查
ON字段是否真走了索引：悬停在内表节点上，看Actual Number of Rows是否远大于Estimated Number of Rows；差距大说明统计信息过期，先跑UPDATE STATISTICS table_name WITH FULLSCAN - 确认连接字段类型严格一致：比如左表是
INT，右表却是VARCHAR(20)，即使建了索引也会隐式转换失效 - 避免在
ON子句里写函数：ON YEAR(o.order_date) = 2026会让索引完全失效，退化为全表扫描
临时禁用Nested Loops验证瓶颈
不改SQL、不加索引，5秒内判断是不是Nested Loops惹的祸：在当前会话执行DBCC TRACEON(2340)，或者更精准地用查询提示OPTION (USE HINT('DISABLE_OPTIMIZED_NESTED_LOOP'))。如果执行计划立刻变成Merge Join或Hash Join，且耗时下降90%，问题定位完成。
-
TRACEON(2340)影响整个实例，只用于测试环境；生产环境优先用查询级提示 - 如果禁用后反而更慢，说明
Hash Join因内存不足spill到tempdb——此时要调max server memory或加OPTION (HASH GROUP, HASH UNION)引导 - 别只关
Nested Loops：确保enable_hashjoin和enable_mergejoin没被意外关掉（查sys.configurations）
长期方案：索引 + 驱动表控制
禁用只是止痛，根治靠两点：被驱动表连接列必须有索引，且驱动表结果集必须小。但“小”不是物理行数少，而是WHERE过滤后预估行数少——这依赖准确的统计信息和干净的WHERE条件。
- 给所有
ON字段建索引，优先覆盖索引：比如JOIN orders o ON u.id = o.user_id，就在orders(user_id)上建非聚集索引，把常用查询字段包含进去 - LEFT JOIN场景下，若左表过滤条件弱（如
WHERE u.status IN (1,2,3)），考虑用子查询提前收缩：把SELECT * FROM users u LEFT JOIN orders o ...改成SELECT * FROM (SELECT id FROM users WHERE status IN (1,2,3)) u LEFT JOIN orders o ... - 彻底规避RIGHT JOIN：SQL Server对它的优化策略极度保守，倾向强制
Nested Loops；一律重写为LEFT JOIN + 显式NULL过滤
容易被忽略的隐性陷阱
很多人加了索引、关了NL，查询还是慢——问题常出在统计信息滞后和数据倾斜上。金仓/KES和SQL Server都存在类似问题：ANALYZE或UPDATE STATISTICS没跑，优化器就按“空表”估算行数，导致Hash Join分配内存严重不足，最终磁盘spill。
- 执行计划里
Hash Match节点出现Warning: No join predicate？立刻检查ON条件是否漏写或写成AND而非=，这是笛卡尔积前兆 - 被驱动表含
TEXT/XML字段时，SQL Server可能把整行拖进哈希表，内存占用暴增；考虑用SELECT明确列出字段，避开大字段 -
STRAIGHT_JOIN在MySQL有效，但在SQL Server不存在；想锁死连接顺序，只能用FORCE ORDER提示，但风险高，仅限已确认驱动表最优时使用
