标量函数在视图中会强制逐行计算，导致性能严重下降；应改用persisted计算列、join替代、内联表值函数或直接嵌入sql逻辑来优化。
视图里调用标量函数会强制逐行计算
视图本身不存储数据，只是保存查询定义；一旦你在 SELECT 列表里写 dbo.F2Y(amount) 这类标量函数，数据库就必须对结果集的每一行都调用一次函数——哪怕最终只取前10条，也得先算完全部行。这不是懒加载，是硬性执行逻辑。
- 函数内部每多一层
SELECT、WHILE或字符串拼接，开销就指数级增长 - SQL Server 不会对标量 UDF 做内联优化，每次调用都有上下文切换、参数序列化等固定开销
- 执行计划里会出现大量
Compute Scalar算子，且“实际行数”和“估计行数”严重偏离，说明优化器已放弃预测
函数让索引和统计信息完全失效
视图底层查的是基表，但只要 SELECT 列里有函数，哪怕只是 UPPER(name)，优化器就无法将 WHERE 条件下推到基表扫描层。更糟的是，它连字段的分布统计都用不上——因为函数输出不可预估。
-
WHERE dbo.GetYear(order_date) = 2023→ 全表扫描，无视order_date上的索引 - 即使函数逻辑极简单（如
ISNULL(x, 0)），SQL Server 仍可能拒绝使用索引查找 - PostgreSQL 对
STABLE函数稍友好，但若函数里有NOW()或子查询，直接报错建视图失败
嵌套视图 + 多个函数 = 性能雪崩
一个视图调用另一个含函数的视图，再被 JOIN 进主查询——这时函数不是调用一次，而是按笛卡尔积级别放大。比如 A 视图返回 1 万行，B 视图每行调用 3 个函数，JOIN 后实际执行函数调用次数可能超 30 万次。
- 实测案例：某报表视图含 7 个自定义函数，单次查询耗时 78 秒；去掉后降到 0.26 秒
- 函数间若存在隐式转换（如
VARCHAR输入进INT返回的函数），还会触发额外类型推导和拷贝 - SQL Server 的
sys.dm_exec_function_stats能查到具体哪个函数拖慢最多，但前提是函数已被执行过
替代方案比“修函数”更有效
别花时间优化函数内部逻辑，优先把函数从视图里踢出去。真正稳定的性能提升来自结构层面调整：
- 用
PERSISTED计算列替代：如amount_yuan AS (amount / 100) PERSISTED，再在该列建索引 - 把函数逻辑拆进 JOIN：比如原
dbo.GetCustomerType(id)，改用LEFT JOIN customer_types ct ON t.customer_id = ct.id - 对必须动态计算的场景，改用内联表值函数（ITVF）：它会被展开成 SQL 片段，参与连接消除和索引选择
- 高频调用的简单转换（如大小写、四舍五入），直接写进视图 SQL，别封装成函数
最易被忽略的一点：视图上建索引（Indexed View）不能包含任何标量函数——哪怕你确认它是确定性的，SQL Server 也会拒绝创建。这点在设计阶段就得卡死。
