标量函数在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函数，整个链路仍会退化为串行
