SQL Server根据表大小、连接字段索引及等值条件选择JOIN算法：小表驱动大表且内表有索引时倾向Nested Loops；两表都大且无序无索引则选Hash Match；需结合执行计划、统计信息更新与索引优化综合判断。
SQL Server怎么选Nested Loop还是Hash Join
SQL Server优化器不是凭空决定用哪种JOIN算法的，它看三样东西：表大小、连接字段有没有索引、连接条件是不是等值。没索引的小表驱动大表，大概率走Nested Loops；两表都大且没排序，又没合适索引，就倾向Hash Match。
你可以用SET STATISTICS XML ON查执行计划，看到PhysicalOp="Nested Loops"或PhysicalOp="Hash Match"就确认了实际用的算法。
- 如果
Nested Loops慢，先检查内表连接列是否有索引——没有的话，外层每行都要全表扫一次内表 -
Hash Match内存占用高，若出现Warning: Hash warning: No join predicate，说明ON条件漏写了，直接退化成笛卡尔积 - 在SSMS里把鼠标悬停在JOIN算子上，能看到“Estimated Row Count”和“Actual Row Count”，两者差太多，说明统计信息过期，
UPDATE STATISTICS可能比改SQL更管用
为什么LEFT JOIN有时比INNER JOIN还快
这反直觉，但真实存在。关键在驱动表选择和NULL传播逻辑。比如LEFT JOIN orders ON users.id = orders.user_id，如果users是小表、orders是大表且user_id无索引，SQL Server可能放弃Hash Match，转而用users作外表跑Nested Loops——而INNER JOIN因优化器误判驱动表，反而选了大表做外表，导致中间结果暴增。
-
LEFT JOIN强制保留左表，优化器不敢轻易交换表顺序；INNER JOIN可互换，有时换来的是更差的执行路径 - 当右表有大量NULL（比如
orders.user_id很多为空），INNER JOIN过滤后结果集变小，但优化器基于旧统计信息仍按大结果预估，分配资源过多，反而拖慢 - 别迷信“LEFT JOIN一定慢”，先看执行计划里哪个表被标为“Outer References”，那就是实际驱动表
Hash Join的build table到底选哪边
SQL Server不严格区分build/probe角色，但行为逻辑类似：它倾向于把**较小的、过滤后更小的、或者有聚集索引的表**当作哈希构建侧。这不是由LEFT/RIGHT语法决定的，而是由优化器基于行数估算和索引可用性动态判断的。
- 如果你写
FROM big_table LEFT JOIN small_table，优化器仍可能把small_table作为build侧——因为哈希表建在小数据上更省内存 - 但如果
small_table加了WHERE条件后几乎没数据，而big_table有强过滤（比如WHERE status = 'active'），优化器可能反转build侧 - 真正影响build侧选择的是
estimated number of rows，不是物理大小。所以SELECT TOP 100 *加在某张表上，可能直接让它变成build侧
嵌套循环里内外表顺序怎么调才有效
手动调顺序只在一种情况下有用：你比优化器更清楚数据分布，且能用FORCE ORDER提示压制默认计划。否则，改FROM a JOIN b为FROM b JOIN a，优化器大概率又给你换回来。
- 想让某表当驱动表，优先确保它满足：行数少、WHERE条件过滤性强、连接列有索引
- 给内表连接列建索引比调顺序管用十倍——
Nested Loops的内层查找从O(N)降到O(log N)，效果立竿见影 -
FORCE ORDER是双刃剑：它锁死表顺序，但后续统计信息更新或数据倾斜时，可能让查询从200ms飙到20s，线上慎用
最常被忽略的点是：JOIN算法选择不是静态配置，它依赖实时统计信息和参数嗅探。一张表今天走Nested Loops，明天批量导入后没更新统计信息，就可能切到Hash Match并OOM。别只盯着SQL写法，UPDATE STATISTICS和监控Actual vs Estimated Rows才是日常要盯住的活。
