标量函数在视图中强制逐行执行，因其被SQL Server视为“黑盒”，无法内联展开，优化器只能为每行单独调用；替代方案包括PERSISTED计算列、JOIN改写、内联表值函数（ITVF）及逻辑直写查询。
标量函数在视图里为什么会强制逐行执行？
因为SQL Server把标量函数（dbo.GetYear、dbo.CalculateTax等）当成“黑盒”，无法内联展开，优化器只能为结果集的每一行单独调用一次。哪怕你只加了TOP 10，它也得先把全表每行都算一遍函数值，再取前10——这不是懒加载，是硬性执行逻辑。
常见错误现象包括：
- 执行计划里大量出现
Compute Scalar算子，且“实际行数”远大于“估计行数” -
WHERE dbo.GetYear(order_date) = 2023导致order_date上的索引完全失效，触发全表扫描 - 嵌套视图中调用多个标量函数时，调用次数按笛卡尔积放大（例如A视图1万行 × B视图每行3个函数 = 实际3万次以上调用）
哪些替代方案能真正绕开逐行计算？
别优化函数内部逻辑，优先把它从视图SELECT列表里移出去。实测显示：含7个标量函数的报表视图耗时78秒，去掉后降到0.26秒。
可用的替代路径有：
- 用
PERSISTED计算列替代：如ALTER TABLE orders ADD tax_amount AS (amount * 0.08) PERSISTED，再对该列建索引 - 把函数逻辑改写进
JOIN：原dbo.GetCustomerType(id)可改为LEFT JOIN customer_types ct ON t.customer_id = ct.id - 换成内联表值函数（ITVF）：
CREATE FUNCTION dbo.GetDiscountInline (@ProductID INT) RETURNS TABLE AS RETURN (SELECT Discount FROM Products WHERE ProductID = @ProductID)，再用CROSS APPLY调用 - 简单逻辑直接写进查询：比如
ISNULL(x, 0)或UPPER(name)，就别封装成函数
为什么内联表值函数（ITVF）比标量函数快？
ITVF不是“调用”，而是被优化器展开成一段SQL片段，参与连接消除、索引选择和谓词下推。而标量函数每次调用都有上下文切换、参数序列化、返回值封装三重开销。
关键区别在于：
- 标量函数返回单个值，必须逐行求值；ITVF返回结果集，可与主查询合并执行计划
- ITVF里不能有
DECLARE、SET、WHILE等过程式语句，结构天然适合优化 - 用
CROSS APPLY调用ITVF时，如果右表有合适索引，执行计划会显示Index Seek而非Compute Scalar
哪些场景下仍可能踩坑？
即使用了ITVF或计算列，以下细节仍会悄悄拖慢查询：
- 基表统计信息长期未更新，优化器误判数据分布，该走索引却选了扫描
- 函数参数类型与字段类型不一致，引发隐式转换（如
VARCHAR输入进INT返回的函数），触发额外类型推导和内存拷贝 - PostgreSQL中函数没标记
IMMUTABLE或STABLE，视图创建直接失败；SQL Server中没加WITH SCHEMABINDING，函数变更可能导致视图失效 - 视图被多层嵌套引用，且每层都带函数或
CROSS APPLY，执行计划深度增加，优化器更容易放弃最优路径
最常被忽略的一点是：视图本身不缓存执行计划，但它的性能表现高度依赖底层表的索引设计和统计信息新鲜度——这两项在上线后往往没人定期维护。
