Adaptive JOIN是SQL Server 2017+在运行时根据右表实际行数动态选择Nested Loops或Hash Join的机制，出现于执行计划中表明优化器启用自适应查询处理，用于应对统计信息滞后、参数化查询选择性波动等预估不准场景。
Adaptive JOIN 是什么，它为什么出现在执行计划里
Adaptive JOIN 不是错误，也不是性能问题的标志，而是 SQL Server 2017+（及 Azure SQL）在运行时动态选择连接策略的一种机制。它出现的前提是：优化器在编译阶段无法准确预估右表行数，于是生成一个“带分支”的计划，在执行到 JOIN 节点时，根据左表实际输出行数，实时决定走 Nested Loop 还是 Hash Join。
常见触发场景包括：
- 右表来自参数化查询，且统计信息陈旧或列值分布极不均匀（比如
@status在'pending'和'shipped'间差异达百倍） - 右表是表变量或未更新统计信息的临时表，优化器只能按“固定基数”估算（如表变量默认估 1 行）
- 查询中用了
OPTION (RECOMPILE)，但右表数据量在每次执行时波动剧烈
Adaptive JOIN 带来的实际影响和坑点
它解决了“计划选错”的问题，但引入了新代价：每个 Adaptive JOIN 节点会多一次运行时判断、可能触发额外内存分配，并且在 Profiler 或 Extended Events 中表现为两个子计划路径（Nested Loop + Hash Match），容易误读为“计划膨胀”或“重复执行”。
关键风险点：
- 如果右表实际行数刚好卡在阈值边缘（SQL Server 默认约 86 行），可能频繁切换策略，导致执行时间抖动
- Hash Join 分支需要足够内存；若
min_grant_percent不足或并发高，会退化为 Grace/Recursive Hash，反而比预编译的 Nested Loop 更慢 - 在含多个 Adaptive JOIN 的深层嵌套中，各节点独立决策，可能组合出非最优路径（比如左路用 NL，右路用 HM，中间数据流不匹配）
什么时候该干预，怎么干预
不需要一看到 Adaptive JOIN 就禁用——它多数时候比硬编码策略更稳。但以下情况建议显式控制：
- 已知右表总是小（OPTION (LOOP JOIN)，避免 Hash 分支开销
- 已知右表总是大（>10 万行）且内存充足：加
OPTION (HASH JOIN)，跳过判断延迟 - 右表是临时表：执行
UPDATE STATISTICS #tmp ON (join_col)后再 JOIN，让优化器有据可依，常能消除 Adaptive 分支 - 使用表变量：改用
DECLARE @t TABLE(..., INDEX ix_join (join_col))（SQL Server 2014+ 支持内联索引），提升基数估算质量
如何确认 Adaptive JOIN 是否真在起作用
别只看图形执行计划里的“Adaptive Join”图标。真正要看的是实际执行后的 XML 计划中 AdaptiveNode 下的 ActualExecutions 和 IsAdaptive 属性：
<RelOp NodeId="3" PhysicalOp="Adaptive Join" ...>
<AdaptiveNode>
<IsAdaptive>true</IsAdaptive>
<ActualExecutions>1</ActualExecutions>
<AdaptiveFeedback>...</AdaptiveFeedback>
</AdaptiveNode>
</RelOp>
如果 ActualExecutions 是 1，说明只走了一条路径，另一条纯属预留；如果反复出现 IsAdaptive="false"，说明优化器已退化回传统编译模式——此时 Adaptive 已失效，该查统计信息或参数嗅探了。
复杂点在于：它不报错、不告警，也不写日志，只有深入 XML 才能确认是否被真正启用。忽略这点，就等于把自适应能力当摆设。
