标量函数导致视图变慢的根本原因是执行模型限制：sql server无法内联展开，被迫逐行调用，且基数估计失效；sql server 2019+支持内联标量函数（需满足确定性、单return、with inline = on等条件）或改用内联表值函数（itvf）替代。
标量函数为什么会让视图变慢
SQL Server 中的标量用户定义函数（UDF）在视图里直接调用，几乎必然导致性能断崖式下跌。根本原因不是函数本身逻辑多复杂，而是执行模型：优化器无法内联展开 UDF，只能对视图结果集的每一行，逐行调用该函数——也就是“每行一次标量计算”。如果视图返回 10 万行，UDF 就被调用 10 万次，且每次调用都走独立执行路径，无法向量化、无法并行、无法利用批模式。
更隐蔽的问题是基数估计失效：UDF 的参数若含列引用（如 @customer_id = t.id），优化器就无法预估其输出分布，会默认按极低基数（如 1 行）估算，进而选择嵌套循环而非哈希连接，进一步放大开销。
SQL Server 2019+ 的内联标量函数（Inline Scalar UDF）
这是唯一能真正解决问题的原生方案。从 SQL Server 2019 开始，只要满足特定条件，标量函数可被自动内联为表达式，等效于把函数体直接“贴”进查询树中，从而获得完整优化能力。
必须同时满足以下条件：
- 函数体只含单个
RETURN语句，且返回值是确定性表达式（不能含GETDATE()、NEWID()、子查询等） - 所有参数类型必须是标量（不支持表值参数）
- 函数不能引用临时表、表变量或动态 SQL
- 创建时需显式指定
WITH INLINE = ON（默认为OFF）
示例：
CREATE OR ALTER FUNCTION dbo.CalculateAge(@birth_date DATE)
RETURNS INT
WITH INLINE = ON
AS
BEGIN
RETURN DATEDIFF(YEAR, @birth_date, GETDATE()) -
CASE WHEN DATEFROMPARTS(YEAR(GETDATE()), MONTH(@birth_date), DAY(@birth_date)) > GETDATE()
THEN 1 ELSE 0 END;
END;
⚠️ 注意：GETDATE() 是非确定性函数，上面这个例子实际会失败。真实可用的内联函数必须用确定性函数，比如 ISNULL()、CONCAT()、DATEADD()（配合常量）等。
替代方案：用内联表值函数（ITVF）模拟标量行为
当业务逻辑无法写成内联标量函数（比如需要查表、调用其他函数、含分支逻辑），就改用内联表值函数（ITVF）。它本质是返回单行单列的表，但因无函数体、无变量声明、仅含一个 SELECT，优化器能完全展开并重写执行计划。
关键点：
- 用
SELECT TOP (1) ... FROM ... WHERE ...确保单行输出（避免运行时报错） - 在视图中用
CROSS APPLY关联，而非直接调用函数 - 确保
ITVF内部查询有合适索引，否则CROSS APPLY仍会退化为每行扫描
示例：
CREATE OR ALTER FUNCTION dbo.GetLatestOrderDate(@customer_id INT)
RETURNS TABLE
AS
RETURN SELECT TOP (1) order_date AS latest_order_date
FROM orders
WHERE customer_id = @customer_id
ORDER BY order_date DESC;
在视图中使用：
SELECT c.name, o.latest_order_date FROM customers c CROSS APPLY dbo.GetLatestOrderDate(c.customer_id) o;
绝对要避开的坑
有些做法看似“绕过函数”，实则更糟：
- 在视图里用
CASE WHEN模拟简单逻辑？可以，但别嵌套太深，否则影响可读性和优化器判断 - 把标量函数结果提前算好存到物理列？可行，但需维护一致性（触发器或应用层双写），且失去实时性
- 用临时表缓存函数结果再 JOIN？只适合极少数静态参数场景；多数情况下，建错索引或没改写 JOIN 才是真瓶颈，缓存只是掩盖问题
- 升级到 Azure SQL 或 SQL Server 2022 就万事大吉？不行。内联标量函数仍要求确定性，且旧版本创建的函数不会自动启用内联，必须显式重建并加
INLINE = ON
最常被忽略的一点：即使启用了内联，只要函数体里出现任意一个非确定性函数（哪怕只是 ISNULL(col, GETDATE())），整个内联就会失败，回退到传统标量执行模式——而你从执行计划里很难一眼看出这点，得靠 sys.dm_exec_query_stats 查 execution_type_desc 字段确认。
