SQL Server执行计划中实际使用的物理JOIN运算符是Merge Join、Nested Loops Join或Hash Join之一；需查看图形计划中连接节点左上角标识或属性面板的PhysicalOp值来确认，而非依据SQL中写的JOIN语法类型。
怎么看执行计划里用了哪种JOIN物理运算符
SQL Server 查询优化器不会按你写的 JOIN 语法字面意思执行，而是根据统计信息、索引、行数估算等选一个它认为成本最低的物理算法。实际执行时用的是 Merge Join、Nested Loops Join 或 Hash Join 中的一种，不是逻辑上的 INNER JOIN 或 LEFT JOIN。打开图形执行计划后，每个连接节点图标左上角会标出具体物理运算符名称（如“Merge Join”），鼠标悬停或双击该节点，看属性面板里的 PhysicalOp 值——这才是真实干活的那个。
为什么明明写了LEFT JOIN，执行计划却显示Merge Join
Merge Join 并不只服务于 INNER JOIN；只要两个输入都按连接列有序（比如都有对应列的聚集索引或排序扫描），SQL Server 就可能为 LEFT JOIN 也选它。但注意：如果右表没有有效排序，Merge Join 就不会出现，哪怕你加了 ORDER BY 也不行——优化器只信索引和统计信息，不信 SQL 里的排序暗示。
- 常见诱因：左表和右表的连接列（如
CustomerID）各自有聚集索引，且查询能利用上 - 风险点：若右表数据量突增但统计信息未更新，
Merge Join可能退化成大量重复扫描，而你从计划里看不出异常，因为ActualRows和EstimateRows差距大但图标仍是“Merge” - 验证方法：在计划中右键该节点 → “属性”，重点看
IsSorted是否为True，以及左右两个子分支的Ordered属性
如何让优化器避开低效的Nested Loops Join
当小表驱动大表、且大表连接列无索引时，Nested Loops Join 会变成“对小表每行，全表扫描大表一次”，性能雪崩。这不是写法错，是缺少支撑条件。
- 必须确保内表（通常是
ON右侧表）连接列上有索引，最好是覆盖索引（含SELECT所需字段） - 如果内表实际行数远超优化器估计值（比如统计信息陈旧），它可能误判为“适合嵌套循环”，此时
UPDATE STATISTICS比强行加OPTION (HASH JOIN)更治本 - 避免在连接条件里用函数或表达式，例如
ON UPPER(a.Name) = UPPER(b.Name)会让所有索引失效，直接锁死Nested Loops
Hash Join出现在执行计划里意味着什么
Hash Join 是 SQL Server 处理“无序大表连接”的主力，但它需要足够内存构建哈希表。一旦内存不足，就会溢出到 tempdb，性能断崖下跌——而图形计划里只显示“Hash Match”，不提示是否发生了溢出。
- 关键线索：看该节点属性中的
Warnings是否为True，再检查ActualExecutions和UsedMemory字段 - 典型触发场景：两个大表做
INNER JOIN，但连接列都没有可用索引，或数据严重倾斜（某连接值占 80% 行数） - 临时缓解：加
OPTION (HASH JOIN)强制，但只是掩盖问题；根本解法是补索引或拆分倾斜值（如把 NULL 单独查出来 UNION ALL）
