查询优化中内联的重要性：优劣场景与执行计划识别

一、先明确什么是查询内联 #

内联本质是查询优化器把模块化的查询逻辑（比如函数、CTE、派生表）展开到主查询中，和主查询的逻辑合并后一起优化，而非作为独立单元执行。

二、内联的核心价值（何时有利） #

1. 内联表值函数（ITVF）的优势 #

• 内联后，优化器可将函数逻辑与主查询的过滤、连接、排序等操作合并，充分利用索引、统计信息生成更优执行计划。
• 不会像标量函数那样强制串行执行，支持并行查询，这也是ITVF性能远超标量函数的核心原因。

2. 单次引用的CTE/派生表 #

对于仅被引用一次的CTE或派生表，内联后优化器能整体评估过滤条件，比如提前将筛选条件推送到底层表，减少数据扫描量，反而比独立执行更高效。

三、内联的问题场景（何时有害） #

1. 重复引用的CTE/派生表 #

如果CTE或派生表被主查询多次引用（比如多JOIN、多SELECT子句重复调用），优化器内联后会重复执行CTE逻辑，而非先计算一次结果再复用。例如：

WITH SalesCTE AS (
    SELECT CustomerID, SUM(Amount) AS TotalSales
    FROM Sales
    WHERE SaleDate >= '2023-01-01'
    GROUP BY CustomerID
)
SELECT 
    c.CustomerName, s1.TotalSales, s2.TotalSales
FROM Customers c
JOIN SalesCTE s1 ON c.ID = s1.CustomerID
JOIN SalesCTE s2 ON c.ID = s2.CustomerID

这里SalesCTE被引用两次，内联后会执行两次SUM(Amount)聚合计算，导致重复扫描Sales表，性能下降。

2. 过于复杂的内联逻辑 #

若内联的函数/CTE本身逻辑复杂（比如多层嵌套、大量计算），内联后主查询逻辑会异常庞大，优化器可能无法在合理时间内生成最优计划，反而降低执行效率。

四、如何在执行计划中识别内联情况 #

1. 内联成功的标识 #

• 执行计划中找不到对应函数、CTE的独立执行节点，逻辑直接合并到主查询的扫描、连接等节点中。比如ITVF被内联后，计划里只会显示底层表的扫描、过滤，看不到函数调用节点。
• CTE被内联时，计划中不会出现CTE Scan节点，直接显示CTE内部的查询逻辑（如表扫描、聚合）。

2. 内联导致重复计算的标识 #

• 执行计划中出现多次相同的扫描/聚合节点，对应原本的CTE/派生表逻辑。比如上述例子中会看到两次对Sales表的聚合计算。
• 查看执行计划的「逻辑读取」统计，重复执行的节点会有较高读取次数。

3. 未内联的标识（如标量函数） #

• 执行计划中会出现Scalar Operator或Compute Scalar节点，且整个查询无Parallelism节点（标量函数强制串行执行）。

总结 #

内联没有绝对的优劣，核心看逻辑是否被复用以及优化器能否有效处理合并后的查询：

• 当模块化逻辑仅被调用一次、合并后能让优化器更好利用索引和统计信息时，内联有利（如ITVF、单次引用的简单CTE）。
• 当模块化逻辑被多次引用、或合并后逻辑过于复杂导致优化器无法生成高效计划时，内联有害（如多次引用的CTE、复杂嵌套的内联逻辑）。

内容的提问来源于stack exchange，提问作者J. Mini