如何在SQL Server 2022中利用子查询内联特性优化标量查询-SQL-PHP中文网

sql server 2022仅对select列表中、无聚合/窗口/top、非相关（或可去相关）、结构简单（无group by/union）的标量子查询自动内联；加option(recompile)可能跳过内联优化；推荐显式改写为left join以确保可控性与索引利用。

如何在sql server 2022中利用子查询内联特性优化标量查询

SQL Server 2022 确实引入了子查询内联（Subquery Inlining）优化机制，但它**仅对特定结构的标量子查询自动生效**，不是所有 SELECT 中的子查询都会被内联。盲目依赖它反而可能掩盖真实性能瓶颈。

哪些标量子查询会被自动内联？

SQL Server 2022 的优化器只对满足以下全部条件的子查询尝试内联：

出现在 SELECT 列表中（即“标量上下文”），且返回单值
不包含聚合函数（如 MAX()、COUNT()）、窗口函数或 TOP
不引用外部查询的列做相关性判断（即非相关子查询，或虽相关但可安全去相关化）
子查询本身是简单 SELECT ... FROM ... WHERE 结构，不含 GROUP BY、HAVING、UNION

例如这个会被内联：

SELECT 
  id,
  (SELECT name FROM departments d WHERE d.id = e.dept_id) AS dept_name
FROM employees e;

而这个不会：

SELECT 
  id,
  (SELECT MAX(salary) FROM employees e2 WHERE e2.dept_id = e.dept_id) AS max_dept_salary
FROM employees e;

因为含 MAX() —— 它走的是嵌套循环 + 聚合执行计划，不是内联。

为什么加 `OPTION(RECOMPILE)` 有时反而让内联失效？

启用 RECOMPILE 会跳过部分查询计划缓存阶段的优化路径，包括子查询内联的识别逻辑。实测中，某些本该内联的场景在加该提示后退化为嵌套循环执行。

仅在需要参数嗅探修正时才用 OPTION(RECOMPILE)，不要把它当“性能万能开关”
若怀疑内联未发生，先用 SET STATISTICS XML ON 查看实际执行计划，搜索关键词 RelOp LogicalOp="Compute Scalar" —— 如果里面还包裹着 RelOp LogicalOp="Nested Loops"，说明没内联成功
内联成功的表现是：原子查询逻辑被“展开”进主表扫描/索引查找中，生成类似 JOIN 的等价计划

手动改写比等内联更可靠

依赖自动内联风险高，尤其在复杂 WHERE 或多层嵌套下。更可控的做法是主动改写为 LEFT JOIN：

-- 原写法（依赖内联）
SELECT 
  e.id,
  (SELECT d.name FROM departments d WHERE d.id = e.dept_id) AS dept_name
FROM employees e;
<p>-- 推荐改写（明确、稳定、可索引利用）
SELECT 
e.id,
d.name AS dept_name
FROM employees e
LEFT JOIN departments d ON d.id = e.dept_id;</p>

这样做的好处：