sql server 2022的iqp不会自动重写或扁平化嵌套查询，仅在执行计划生成阶段对低效模式（如预估偏差导致的嵌套循环抖动）做运行时自适应调整，如adaptive joins切换连接方式或interleaved execution获取真实基数，前提为兼容级别≥150且满足特定可适配模式。
SQL Server 2022 的智能查询处理（Intelligent Query Processing, IQP）不会自动“重写”或“扁平化”嵌套查询逻辑，它不改变你写的 SELECT ... WHERE id IN (SELECT ...) 或 FROM (SELECT ...) AS t 结构。它只在执行计划生成阶段，对已识别的低效模式做运行时自适应调整。
嵌套查询本身不会被 IQP 自动转成 JOIN 或 CTE
很多人误以为开了 IQP 就能“一键优化子查询”，实际不是。SQL Server 不会把 WHERE id IN (SELECT user_id FROM logs WHERE status = 'error') 自动替换成等价 JOIN。语义正确性由你负责，IQP 只管怎么更稳、更快地执行你写的这个结构。
- 如果你写了相关子查询（correlated subquery），比如
(SELECT AVG(score) FROM grades g WHERE g.student_id = s.id)，IQP 不会把它提取成 APPLY 或预计算；但若该子查询被多次调用且数据分布倾斜，Batch Mode on Rowstore（需兼容级别 150+）可能通过向量化减少重复计算开销 - CTE 和派生表（derived table）仍按原有语义展开，IQP 不介入重写——除非你显式加
OPTION (USE HINT('ENABLE_QUERY_OPTIMIZER_HOTFIXES'))配合其他机制 - 真正起作用的是 IQP 中的
Adaptive Joins和Memory Grant Feedback：当嵌套循环（Nested Loop）因预估行数严重不准导致内存不足或回表爆炸时，运行时可能切到 Hash Join；但这只发生在 JOIN 节点，不改变子查询语法树
哪些嵌套场景 IQP 实际能干预？
只有当嵌套查询触发了 SQL Server 明确建模的“可适配模式”时，IQP 才会生效。最常见的是以下两类：
-
TOP+ 嵌套聚合：例如SELECT TOP 10 * FROM orders o WHERE o.customer_id IN (SELECT c.id FROM customers c WHERE c.region = 'US')。若外层TOP导致优化器低估内层结果集大小，Row Goal误判会引发嵌套循环反复扫描。此时Adaptive Joins在首次执行后收集实际行数，下次编译可能改用 Hash Join 避免抖动 - 含聚合的多层派生表：如
SELECT * FROM (SELECT category, SUM(sales) s FROM sales GROUP BY category) t1 JOIN (SELECT category, COUNT(*) c FROM returns GROUP BY category) t2 ON t1.category = t2.category。若两子查询输出行数差异极大（比如某品类退货为 0），Interleaved Execution（需数据库兼容级别 ≥ 140，且子查询在 FROM 中）会让优化器在执行第一层时暂停，取真实基数再生成第二层计划，避免因预估偏差导致内存分配过小或排序溢出
为什么你常感觉 IQP “没起作用”？
因为绝大多数嵌套查询卡顿的根本原因，不在 IQP 的覆盖范围内：
- 驱动表选择错误：比如
WHERE id IN (SELECT huge_table.id FROM huge_table)，优化器仍可能选错内外表顺序，而Adaptive Joins只适用于 INNER/LEFT JOIN，对IN子句中的半连接（semi-join）无效 - 缺少索引支撑：子查询中
WHERE条件列无索引，导致每次都要全表扫描——IQP 不会帮你建索引，也不会提示缺失索引 - 兼容级别低于 150：SQL Server 2022 默认兼容级别是 160，但很多升级实例仍设为 140 或 150。部分 IQP 功能（如
Table Variable Deferred Compilation）要求 ≥150，而Batch Mode on Rowstore要求 ≥150 且至少有一列有筛选性非空索引 - 参数嗅探干扰：带参数的嵌套查询（如
WHERE id IN (SELECT id FROM t WHERE status = @p)）若第一次用低选择率参数编译，后续高选择率执行就会卡死——Optimize for Ad Hoc Workloads或Query Store强制计划强制更有效，IQP 不处理这类缓存污染
真正要让嵌套查询变快，得先确认它是不是必须嵌套：能用 EXISTS 替代 IN 就别用 IN；能提前物化中间结果到临时表并加索引，就别靠多层派生表硬扛；IQP 是手术刀，不是创可贴——它修的是执行过程里的“意外抖动”，不是你一开始就把查询写歪了的问题。
