标量udf在嵌套查询中逐行调用导致性能灾难；sql server无法内联含非确定性操作、查表或嵌套调用的函数；应改用内置函数、outer apply或内联表值函数替代。
标量UDF在嵌套查询里被逐行调用，根本停不下来
SQL Server 对标量用户定义函数（scalar UDF）的执行方式是「每行调用一次」——只要它出现在 SELECT、WHERE 或 JOIN 条件中，且引用了外层表字段，就会触发标量计算循环。嵌套查询（比如 WHERE col IN (SELECT ...) 或子查询中调用 dbo.fn_CalcTax()）会让这个行为叠加：外层每行 → 进入子查询 → 子查询每行再调用一次 UDF → 可能还嵌套多层。结果就是 CPU 暴涨、执行计划里全是 Compute Scalar 节点，且无法并行。
优化器无法内联或重写，索引也帮不上忙
SQL Server 2019+ 虽支持部分标量 UDF 内联（SCHEMABINDING + deterministic），但前提是函数体不含以下任一内容：
-
GETDATE()、NEWID()等非确定性函数 - 对表/视图的访问（哪怕只读）
- 显式事务或
PRINT/RAISERROR - 嵌套调用另一个标量 UDF
绝大多数业务 UDF 都踩中至少一条，导致优化器只能把它当黑盒处理，既不能下推过滤条件，也无法利用 user_id 上的索引跳过计算——哪怕你写了 WHERE dbo.fn_IsVIP(u.id) = 1，SQL Server 仍会先扫全表再逐行调用函数。
替代方案不是“换个写法”，而是换掉标量UDF本身
别试图给标量 UDF 加索引或加 WITH SCHEMABINDING 就万事大吉。真正有效的路径是：
- 把纯计算逻辑（如日期加减、字符串拼接）直接写进查询，用内置函数替代，例如用
DATEADD(day, 30, order_date)替代dbo.fn_Add30Days(order_date) - 涉及查表逻辑（如“取用户最近订单状态”）改用
OUTER APPLY或LEFT JOIN，配合orders(user_id, created_at)复合索引 - 实在绕不开复杂逻辑？改写为内联表值函数（
ITVF），它可被优化器展开、支持索引推送，性能接近原生 JOIN
标量 UDF 的坑不在语法错，而在它天然违背集合运算原则——只要它还在嵌套查询里被调用，就等于主动放弃 SQL Server 的大部分优化能力。
