LOOP JOIN拉高CPU使用率因其嵌套循环机制：外表每行触发内表全表扫描，尤其当外表行数多、内表无索引或驱动表误判时，CPU持续消耗于重复读页与比对。
为什么LOOP JOIN会拉高CPU使用率
LOOP JOIN本质是嵌套循环：外表每行，都触发一次内表的查找或扫描。如果外表有10万行、内表没索引，每次都要全表扫描，CPU就全耗在反复读页、比对、跳转上了。更隐蔽的是，SQL Server有时会“误判”驱动表——把大表当外表，小表当内表，结果本该走Hash Match的场景硬被优化器选成Nested Loop，CPU直接飙到100%。
用执行计划定位LOOP JOIN是否异常
打开SET STATISTICS XML ON，跑SQL，看图形执行计划里有没有标着“Nested Loops”的图标。重点盯三点：
- 箭头输入行数：如果外表（左输入）显示“Estimated Rows”几十万甚至上百万，但实际业务只查最近7天数据，说明过滤没下推，JOIN前没裁剪
- 内表访问方式：右输入如果是“Table Scan”或“Clustered Index Scan”，基本可以判定缺索引；如果是“Index Seek”，再看Seek谓词是否用了SARGable条件（比如
col = @val可以，YEAR(col) = 2024就不行） - CPU cost占比：鼠标悬停在Nested Loops图标上，看“Estimated CPU Cost”是否占整个计划80%以上——这是典型信号
改写SQL让LOOP JOIN变可控
不是所有LOOP JOIN都要干掉，关键是让它只处理“真需要的数据”。常见有效手段：
- 把WHERE条件尽可能提前：不要写
FROM A LEFT JOIN B ON ... WHERE B.status = 'done'，这会让LEFT JOIN先全量关联再过滤，B表的NULL行也参与了循环；改成子查询先筛B：FROM A LEFT JOIN (SELECT * FROM B WHERE status = 'done') AS B ON ... - 显式控制驱动表顺序：用
OPTION (FORCE ORDER)或INNER LOOP JOIN提示，但必须配合SET STATISTICS IO ON验证逻辑读是否下降——否则只是把问题从CPU转移到IO - 检查JOIN列类型是否一致：比如
A.id INT和B.ref_id VARCHAR(20)连，SQL Server会隐式转换，导致索引失效，被迫扫描，循环次数爆炸
最容易被忽略的细节：统计信息过期 + 参数嗅探
即使SQL写得再规范，这两点也能让LOOP JOIN突然变慢：
- 统计信息陈旧：外表行数预估偏差10倍以上，优化器就可能选错算法。运行
UPDATE STATISTICS 表名 WITH FULLSCAN（大表慎用）或至少WITH SAMPLE 30 PERCENT - 参数嗅探陷阱：第一次用
@date = '2020-01-01'编译，优化器按历史冷数据选了LOOP；之后用@date = '2026-09-28'执行，热数据却复用旧计划。加OPTION (RECOMPILE)临时救急，长期要拆分逻辑或用局部变量打断嗅探
真正卡住的往往不是JOIN本身，而是过滤时机、索引覆盖、统计质量这三者叠加出的“完美风暴”。盯着执行计划里的行数估算和物理操作，比背口诀管用得多。
