SQL Server中Nested Loop JOIN导致CPU飙升，主因是外表行数过多、内表缺索引或优化器误判驱动表；需结合执行计划预估行数、扫描类型、CPU占比及IO/Time统计综合判断，并检查统计信息与参数嗅探问题。
SQL Server 中 Nested Loop JOIN 导致 CPU 飙升，基本可以断定是它被用在了不该用的场景——外表行数远超千行、内表缺索引、或优化器误判驱动表顺序。这不是算法本身有错，而是执行计划“选错了人”。
看执行计划里 Nested Loops 图标上的三个关键信号
打开 SET STATISTICS XML ON，跑 SQL，重点盯图形执行计划中标着 “Nested Loops” 的节点：
- 左输入（外表）的
Estimated Rows是否远高于业务实际——比如查最近 1 天订单，却显示预估 50 万行，说明 WHERE 条件没下推，JOIN 前没过滤 - 右输入（内表）是否是
Table Scan或Clustered Index Scan；如果是Index Seek，再检查 Seek 谓词里有没有隐式转换（如id = @id但@id是VARCHAR）、函数包装（如YEAR(order_date) = 2024），这些都会让索引失效 - 鼠标悬停在 Nested Loops 节点上，看
Estimated CPU Cost占整个计划比例——超过 70% 就是典型瓶颈信号
用 SET STATISTICS IO + TIME 快速定位哪一步在吃 CPU
执行计划有时会“骗人”，尤其当统计信息过期时。更直接的办法是开两个开关，看真实资源消耗：
- 先运行
SET STATISTICS IO ON; SET STATISTICS TIME ON; - 再执行你的完整 SQL（含临时表、CTE、多次 JOIN）
- 关注输出里
logical reads极高但elapsed time远大于CPU time的步骤——这说明大量时间花在循环比对和页跳转上，而非磁盘等待 - 如果某次 INSERT INTO #temp 后续 JOIN 的逻辑读暴增，大概率是临时表没统计信息，优化器瞎估行数，把大结果当小结果用了 Nested Loop
临时禁用优化嵌套循环（OPTIMIZED = True）验证是否真凶
SQL Server 2016+ 引入了“优化嵌套循环”（带批处理排序），它本意是加速小数据量场景，但一旦触发，OPTIMIZED="True" 的 Nested Loops 节点常伴随极高 CPU 和内存授予（RESOURCE_SEMAPHORE 等待）。这不是你写的 SQL 有问题，是优化器自己加戏过头了：
- 当前查询级别禁用：在语句末尾加
OPTION (USE HINT ('DISABLE_OPTIMIZED_NESTED_LOOP')) - 实例级禁用（测试环境慎用）：执行
DBCC TRACEON(2340, -1) - 禁用后如果 CPU 立降、执行计划变成
Hash Match或Merge Join，且logical reads没暴涨，基本坐实问题出在优化版 Nested Loop 上
最容易被忽略的两个底层陷阱
很多人改完 SQL、加完索引、关掉 OPTIMIZED，CPU 还是高——往往卡在这两个点：
-
UPDATE STATISTICS没做：外表或内表的统计信息陈旧（比如上次更新是半年前），导致优化器把 10 万行估成 100 行，硬选 Nested Loop。对大表至少跑UPDATE STATISTICS 表名 WITH SAMPLE 30 PERCENT - 参数嗅探未处理：第一次用
@date = '2020-01-01'编译，优化器按冷数据选了 Nested Loop；之后用热日期执行，却复用旧计划。临时解法是加OPTION (RECOMPILE)，长期得拆分逻辑或用局部变量“断开嗅探链”
真正难的不是识别 Nested Loop，而是判断它该不该出现——同一句 SQL，在不同数据分布、不同参数值、不同统计信息版本下，可能今天走 Hash，明天就切回 Nested Loop。排查必须带着“动态视角”，盯着行数预估、实际读取、CPU/IO 比例三者是否自洽。
