SQL Server选Merge Join需两表连接列有序（如聚集索引），选Nested Loop需驱动表小且内表有高效索引；执行计划中出现Sort算子或内表Scan Count过高即表明当前策略非最优。
看执行计划里两个表的排序状态和数据量分布，而不是凭经验猜。SQL Server优化器选 Merge JOIN 或 Nested Loop JOIN 的依据很具体：前者要求至少一个连接列上有可用的有序扫描路径（比如聚集索引或已排序的索引），后者更依赖驱动表小 + 被驱动表有高效索引查找能力。
检查执行计划中是否有 Sort 算子
如果执行计划里在 Merge Join 节点之前出现 Sort 操作，说明两表原本无序，SQL Server被迫先排序再归并——这时 Merge JOIN 实际开销可能比 Loop JOIN 还高。
- 真实场景中，
Sort是 I/O 和 CPU 双重负担，尤其当连接字段没索引、又没覆盖统计信息时，Sort会吃掉大部分时间 - 如果两表都按
JOIN字段升序排列（比如都是按id建的聚集索引），Merge Join节点前后就不会有Sort，这才是它发挥优势的典型条件 - 用
SET STATISTICS XML ON查看执行计划，重点盯<RelOp LogicalOp="Sort">是否出现在Merge Join上游
对比驱动表行数与内表索引查找成本
Nested Loop JOIN 的实际代价 = 外表行数 × 内表单次查找开销。这个“单次查找开销”取决于索引深度和是否能走 Seek。
- 用
sys.dm_db_index_physical_stats查内表索引的index_depth：深度为 3 意味着一次Index Seek至少读 3 页；若深度是 5，1000 行驱动就要读约 5000 页 - 外表行数超过 1 万且内表索引选择性差（比如
status列只有 3 个值），Nested Loop很容易退化成多次扫描，此时即使没Sort，Merge JOIN 也可能更稳 - 注意：
WHERE条件过滤后的外表行数才是关键，不是原始表总行数——用Actual Number of Rows（不是 Estimated）判断
警惕“看似有序实则失效”的索引
即使连接列上有索引，也不代表 Merge JOIN 就能用上。常见陷阱包括：
- 索引是
NONCLUSTERED但未包含所有SELECT字段，导致 Key Lookup 后数据流不再保序，优化器弃用 Merge - 连接条件用了函数或表达式，如
ON YEAR(o.order_date) = YEAR(c.birth_year)，索引无法用于排序匹配 - 多列索引顺序与
JOIN条件不一致，比如索引是(a, b)，但写的是ON b = x，SQL Server 无法利用该索引做有序归并
真正决定用哪个的，从来不是“哪个听起来高级”，而是执行计划里那几行真实的 Estimated Number of Rows、Index Seek 深度、有没有 Sort，以及你能否控制驱动表大小和索引结构。一旦发现 Merge Join 前面拖着个大大的 Sort，或者 Nested Loop 里内表 Scan Count 高到离谱，就该去调索引或改写查询了，而不是换提示词硬压执行计划。
