标量函数在SQL视图中必然导致性能骤降，因其强制逐行计算、阻断谓词下推、禁用并行；WHERE中使用还会使索引失效，正确做法是将逻辑外移到查询条件或预计算表中。

在 SQL 视图中调用自定义标量函数，几乎必然导致性能骤降——这不是配置问题，而是数据库引擎的执行模型决定的。标量函数会强制逐行计算、阻断谓词下推、禁用并行，三者叠加后，10 万行查询可能退化成 10 万次独立函数调用。

标量函数在视图里会强制逐行计算

视图只是查询的封装，不缓存结果。一旦 SELECT 列表里出现 dbo.CalculateTax(amount) 这类标量函数，SQL Server 就必须对最终结果集的每一行都调用一次函数，哪怕你只加了 TOP 10 或 WHERE id = 123，也得先算完整个基表再过滤。

• 执行计划里会出现大量 Compute Scalar 算子，且“实际行数”远高于“估计行数”，说明优化器已放弃预测
• 函数内部哪怕只有一层 SELECT（比如查一张小码表），也会触发嵌套循环，I/O 放大 N 倍
• sys.dm_exec_function_stats 可查出耗时最高的函数，但前提是它已被执行过（首次调用不计入）

WHERE 条件里用函数会让索引完全失效

写 WHERE dbo.GetYear(order_date) = 2024，等价于告诉优化器：“别管 order_date 上有没有索引，全表扫一遍再算”。因为函数输出不可静态分析，优化器无法确认该表达式是否可逆、是否单调、是否满足索引查找语义。

• 常见陷阱包括：UPPER(name)、YEAR(created_at)、CONVERT(VARCHAR, dt, 120)、任意用户定义标量函数
• MySQL/PostgreSQL 会进一步降级为 ALGORITHM = TEMPTABLE，先物化整个视图结果再过滤
• 正确写法是把函数逻辑外移：WHERE order_date >= '2024-01-01' AND order_date

标量函数直接禁用并行执行计划

SQL Server 中，只要视图定义里含标量 UDF，整个查询就自动退化为串行——不是没开 MAXDOP，是优化器编译阶段就拒绝生成并行计划。PostgreSQL 虽支持 PARALLEL SAFE 属性，但默认为 UNSAFE，且绝大多数自定义函数不满足并行安全要求。

• 检查方法：用 sys.dm_exec_query_plan 查 XML 执行计划，搜索 Parallel="1"，为空即被禁用
• SQL Server 2019+ 的“标量 UDF 内联”仅对极简函数生效（无循环、无临时表、无子查询），复杂逻辑仍无效
• 真正能恢复并行的，只有把函数体展开成纯 SQL 表达式，或改用内联表值函数（ITVF）

嵌套视图 + 多个函数 = 性能雪崩

一个视图调另一个含函数的视图，再被 JOIN 进主查询，函数调用次数不是相加，而是按笛卡尔积级别放大。比如 A 视图返回 5000 行，B 视图每行调 3 个标量函数，JOIN 后实际执行函数调用可能超 1.5 万次——而这些调用全部串行、无法下推、无法索引加速。

• 实测案例：某报表视图含 7 个自定义标量函数，单次查询耗时 78 秒；全部移出后降到 0.26 秒
• 替代方案优先级：PERSISTED 计算列 > JOIN 预计算表 > ITVF > 直接展开表达式
• 最易被忽略的一点：即使函数被标记为 PARALLEL SAFE，只要它内部调用了 GETDATE() 或任何 UNSAFE 函数，整个链路仍会退化为串行