nested loop在小结果集且内表有索引时高效，若执行计划显示nested loop却很慢，主因是内表缺失索引或存在隐式类型转换导致全表扫描；hash join适用于大表等值连接且无索引场景，但出现“no join predicate”即为笛卡尔积风险。
Nested Loop 在小结果集 + 有索引时更快；Hash Join 在大表等值连接、无索引时更稳——但“更快”不等于“更优”，关键看执行计划里实际走的是哪条路，而不是它写了什么。
看到 Nested Loop 却很慢，先查内表有没有索引
常见错误现象是：执行计划显示 Nested Loops，但查询耗时飙升，尤其外层返回几百行、内表却要全表扫描。这是因为优化器误判了内表访问成本——它以为连接列有索引，而实际上没有。
- 每轮循环触发一次内表全表扫描，总成本 ≈ 外表行数 × 内表行数
- 检查方式：悬停在执行计划的内表节点上，看是否出现
Index Seek或Index Scan；若只有Clustered Index Scan或Table Scan，基本就是索引缺失 - 特别注意隐式类型转换，比如
INT字段和VARCHAR字段用=连接，会导致索引失效，外表哪怕只 1 行，内表也得扫全表
Hash Join 出现 “No join predicate” 就等于崩溃
这是 Hash Join 最危险的信号。一旦执行计划里出现这个警告，说明 ON 条件漏写了，实际执行就是笛卡尔积。
- 两表各 1 万行，结果就是 1 亿行；内存瞬间打满，大量写入 tempdb，I/O 直接拉满
- SQL Server 中可通过
SET STATISTICS XML ON查看执行计划，重点核对EstimateRowCount和ActualRowCount是否严重偏离（比如预估 100 行，实际跑出 500 万行） - 如果偏差大，不是 Hint 能救的，得先
UPDATE STATISTICS或重建统计信息
强制用 Hash Join 不一定提速，反而可能更慢
有人发现加了 OPTION (HASH JOIN) 后变快，就以为“Hash 总比 NL 好”，这是典型归因错误。
- 真正起作用的，往往是这个 Hint 顺带“锁死”了驱动表顺序，避免优化器选错外表（比如把 500 万行的表当驱动表）
- 但 Hash Join 严重依赖内存：
max server memory分配不足时，会频繁 spill 到磁盘，性能反不如带索引的 NL - 如果内表本身很小（Index Seek 更轻量
最常被忽略的一点：执行计划里的“驱动表”和你写的 FROM A JOIN B 顺序无关，SQL Server 优化器会重排。但 LEFT JOIN 会强制左表为驱动表，有时候它反而比 INNER JOIN 快——不是语法玄学，是优化器被“锁死”后避开了更差的选择。
