自适应连接仅对inner join生效，需满足：右表估算行数在100–90,000间、兼容级别≥150、原计划倾向hash join、无干扰查询提示。
SQL Server 2022 的自适应连接（Adaptive Join）不是“开箱即用”的性能银弹，它只在特定条件下自动启用，且默认行为常被误读为“智能切换”，实际需配合统计信息、行数估算精度和查询结构共同生效。
自适应连接触发的前提条件有哪些
自适应连接不是所有 JOIN 都能用，它只对 INNER JOIN 生效，且必须满足以下全部条件：
- 优化器估算的右表（inner input）行数落在一个狭窄区间内：通常为 100 行到约 90,000 行之间（具体阈值由内部启发式算法动态计算，不公开）
- 执行计划中该 JOIN 原本会生成
Hash Join，但因估算不准可能退化为低效的Nested Loops；此时 SQL Server 2022 插入一个Adaptive Join算子，在运行时根据实际流入右表的第一批数据量决定最终走 Hash 还是 Loop - 数据库兼容级别必须 ≥ 150（SQL Server 2019 起引入，2022 默认支持，但若库仍设为 140 则完全不启用）
- 不能有
OPTION (RECOMPILE)或OPTION (USE HINT('DISABLE_OPTIMIZER_ROWGOAL'))类提示干扰估算逻辑
为什么执行计划里看到 Adaptive Join 却没提速
常见现象是执行计划 XML 中出现了 Adaptive Join 节点，但实际耗时没变甚至更长——根本原因在于“自适应”本身有开销，且容易被掩盖：
- 它依赖
Actual Number of Rows和Estimated Number of Rows的偏差程度：如果偏差＜3 倍，自适应基本不触发切换，全程按原计划走；偏差过大（如 10 倍以上），说明统计信息严重过期，UPDATE STATISTICS ... WITH FULLSCAN比等自适应更有用 - 自适应决策点发生在右表数据首次批量到达时（通常是前 100 行），若右表扫描本身慢（比如缺索引导致 Table Scan），那还没走到决策点就已卡住
- 执行计划里显示
Adaptive Join≠ 实际发生了切换；要看AdaptiveJoinType属性值是Hash还是NestedLoops，以及下方两个分支的ActualRows是否只有一个非零
如何验证并安全启用自适应连接
不要靠猜，用实际执行计划 + 动态管理视图交叉验证：
- 开启实际执行计划：
SET STATISTICS XML ON，运行查询后在 SSMS 中点击“显示执行计划”，找到<relop logicalop="Adaptive Join"></relop>节点 - 检查右侧输入是否带
Ordered="true"：如果是，说明它本可走 Merge，但优化器因估算犹豫而选了 Adaptive —— 这反而是索引或统计问题，不是 Adaptive 的用武之地 - 查
sys.dm_exec_query_stats中该查询的last_execution_time和total_logical_reads，对比加OPTION (USE HINT('DISABLE_BATCH_MODE_ADAPTIVE_JOINS'))后的数值，若差异＜5%，说明 Adaptive 几乎没起作用 - 生产环境慎用强制提示：
OPTION (USE HINT('ENABLE_BATCH_MODE_ADAPTIVE_JOINS'))仅在调试时临时加，上线前必须回归测试，因为 Batch Mode 本身依赖列存索引，普通行存表加了也无效
比自适应连接更值得优先做的三件事
自适应连接是“补救型”机制，真正影响 JOIN 性能的硬核点仍在基础层：
- 确保
JOIN字段上有匹配顺序的索引：比如ON a.x = b.y，则a表需有以x为首列的索引，b表需有以y为首列的索引，且类型完全一致（INT对INT，非BIGINT） - 把强过滤条件（如
WHERE status = 'Active'）尽量提前写进ON子句或驱动表的子查询中，让优化器早剪枝，避免 Adaptive 被迫处理百万级中间结果 - 禁用
SELECT *：自适应连接对宽表尤其敏感，字段越多，Hash 构建内存压力越大，越容易触发Hash warning: Hash bailout写 tempdb，此时 Adaptive 不是帮手而是负担
自适应连接的真实价值，是在你已经做好索引、统计、语义清晰的前提下，为那 5% 估算临界区的查询兜底。它不替代基础优化，只在基础扎实时才露出一点锋芒。
