相关子查询未触发自适应联接，是因为必须同时满足三个硬性条件：兼容级别为150、子查询被重写为cross/outer apply、内侧行数偏差超2倍且总行数超10000；此外还需启用批处理模式（列存储或trace flag 11256），否则即使计划中显示adaptive join也不会激活。
为什么相关子查询没触发自适应联接？
SQL Server 2019 的自适应联接（Adaptive Join）不会自动作用于任意相关子查询，它只在特定执行路径下生效。最常见误判是：看到 APPLY 或 EXISTS 就以为能触发——其实必须满足三个硬性条件：
- 数据库兼容性级别必须为
150（ALTER DATABASE [db] SET COMPATIBILITY_LEVEL = 150），且已执行DBCC FREEPROCCACHE清空旧计划 - 子查询需被优化器重写为
CROSS APPLY或OUTER APPLY，而非保留原始WHERE EXISTS (SELECT ...)结构；可通过实际执行计划确认是否出现Adaptive Join运算符节点 - 内侧（子查询侧）估算行数与实际偏差 > 2 倍，且总行数 > 10000；若子查询返回仅几百行，即使偏差大，也不会切换
如何确认自适应联接是否真正启用？
不能只看执行计划里有没有 Adaptive Join 标签——它可能被生成但未激活。关键要看运行时行为：
- 启用实时查询统计：
SET STATISTICS XML ON，执行后在实际执行计划中查找<relop nodeid="X" physicalop="Adaptive Join"></relop>节点，并检查其Adaptive="true"属性是否为true - 观察
Actual Number of Rows和EstimateRows是否存在显著差异；若差异大但仍走Nested Loops，说明未触发切换——此时可能是批处理模式未启用 - 批处理模式（
Batch Mode）是前提：只有列存储索引、或启用了行存储批处理（trace flag11256）的场景下，Adaptive Join才会干预；普通行模式（Row Mode）下它完全不工作
排查时容易忽略的兼容性陷阱
即使设了 COMPATIBILITY_LEVEL = 150，以下情况仍会导致自适应机制静默失效：
- MSTVF（多语句表值函数）内含临时表、
INSERT或CREATE TABLE——交错执行（Interleaved Execution）被禁用，外层对 MSTVF 的行数估算回归固定 100 行，Adaptive Join失去切换依据 - 子查询中使用了
UPPER()、RTRIM()等函数谓词，而未开启ENABLE_QUERY_OPTIMIZER_HOTFIXES或对应 CU 补丁（如 KB4538497），导致基数估计严重失真，估算行数从一开始就不靠谱 - 查询启用了参数化（如简单参数化或强制参数化），但参数敏感计划（
PSP）干扰了行数反馈路径，使得运行时无法收集真实数据驱动切换决策
替代验证路径：用 sys.dm_exec_query_profiles 实时观测
当执行计划静态分析不够时，直接查运行时状态更可靠。该 DMV 能暴露自适应联接是否真的在“途中切换”：
- 执行目标查询前，先记下
session_id和request_id - 在另一会话中轮询：
SELECT node_id, physical_operator_name, row_count, estimate_row_count FROM sys.dm_exec_query_profiles WHERE session_id = @sid AND request_id = @rid - 若某
node_id对应physical_operator_name = 'Adaptive Join'，且row_count显著大于estimate_row_count，再观察后续几秒内该节点是否变为'Hash Join'或保持'Nested Loops'——变则已切换，不变则未触发
真正难缠的不是“怎么开”，而是“开了却没用”——自适应联接依赖一整条数据反馈链：正确估算 → 实际执行 → 行数捕获 → 决策切换。任一环节断裂，它就退回旧逻辑，而这个断裂点往往藏在 MSTVF 定义、函数谓词或批处理模式开关里。
