SQL Server实际执行计划中通过PhysicalOp属性确认Join类型：Hash Match对应Hash Join，Merge Join对应Merge Join，Nested Loops对应Nested Loop Join；必须使用实际执行计划（如SET STATISTICS XML ON或SSMS中Ctrl+M）而非估计计划，以避免统计信息过期导致误判。
直接看执行计划里的 Hash Match 或 Merge Join 节点，再结合表大小、索引和排序状态判断——不是靠猜，是靠查。
怎么看执行计划里实际用了哪种JOIN
在 SQL Server 中运行 SET STATISTICS XML ON 后执行查询，或在 SSMS 里按 Ctrl+M 开启“显示实际执行计划”，然后找最外层的 RelOp 节点下的 PhysicalOp 属性值：
-
PhysicalOp="Hash Match"→ 当前走的是 Hash Join -
PhysicalOp="Merge Join"→ 当前走的是 Merge Join -
PhysicalOp="Nested Loops"→ 当前走的是 Nested Loop
注意：别只看“估计执行计划”，它可能因统计信息过期而误判；必须用“实际执行计划”才能确认真实路径。
什么情况下 SQL Server 倾向选 Hash Join
Hash Join 不依赖索引，但极度依赖内存和“小表建哈希、大表探测”这个逻辑。它常被选中当：
- 连接列上 没有可用索引（尤其是大表没索引时）
- 两个表都较大，且其中一张明显更小（比如 10 万 vs 500 万行），优化器选小表做 Build 端
- 连接条件是等值（
=），且字段类型兼容（如INT对INT，避免隐式转换） - 内存足够：Build 阶段需把小表全载入内存建哈希表；若内存不足会溢出到
tempdb，性能断崖下跌
典型反例：Orders 和 Customers 连接，但 Customers.id 没索引、Orders.customer_id 也没索引，且 Customers 行数 20 万，Orders 行数 800 万 —— 这种大概率触发 Hash Join，但也可能因内存压力退化成慢查询。
什么情况下 SQL Server 更可能用 Merge Join
Merge Join 的硬性前提只有一个：**两个输入都已按连接列排序**。它不建哈希表，也不反复索引查找，而是“双指针归并”。所以：
- 两张表的连接列上都有 有序索引（聚簇索引 or 非聚簇但含
ORDER BY的覆盖索引） - 或者其中一张表通过索引扫描天然有序，另一张通过
ORDER BY强制排序（但代价高，一般不推荐） - 连接条件仍是等值；不支持
或 <code>BETWEEN这类非等值连接 - 两表数据量差异不大时优势明显；若一表极小，优化器通常仍倾向 Nested Loop
容易忽略的坑：WHERE 条件如果导致索引无法跳过排序（比如用 LIKE '%abc' 或函数包装列），即使有索引，SQL Server 也可能放弃 Merge Join 路径。
强制切换 JOIN 类型要小心这几点
用 OPTION (HASH JOIN) 或 OPTION (MERGE JOIN) 可以干预，但风险明确：
-
HASH JOIN强制后，若 Build 表意外很大（比如加了WHERE后仍剩 200 万行），内存不够就会大量写tempdb，IO 拉垮 -
MERGE JOIN强制后，若任一输入未真正有序（比如索引失效、统计信息陈旧），执行时会先额外排序，反而比 Hash 还慢 - 禁用某类 JOIN（如
SET STATISTICS XML OFF; SET ENABLE_NESTLOOP OFF）会影响整个会话，别在生产环境乱设
真正该动手的地方，往往不在 JOIN 类型本身，而在补索引、更新统计信息、拆分大表或重写 WHERE 条件——这些才是让优化器“愿意选对路”的底层支撑。
