存储过程调用比函数慢的关键在于执行上下文切换：exec 调用需完整批处理解析、计划查找和事务初始化，而标量函数可内联到查询树中，不启新执行环境。
存储过程调用为什么比函数慢？关键在执行上下文切换
SQL Server 中，EXEC 调用存储过程会触发完整的批处理解析、计划缓存查找、事务上下文初始化；而 SELECT dbo.fn_get_value() 这类标量函数调用，会被内联到查询树中（若为内联表值函数则更轻），不单独启动新执行环境。实际压测发现，高频调用标量 UDF 时，CPU 时间可能反超存储过程——不是因为“函数快”，而是因为 SQL Server 对标量函数做了逐行求值，且无法并行。
- 标量 UDF 在 SELECT 中每行调用一次，执行次数 = 结果集行数；存储过程只执行一次，但内部循环逻辑仍由你自己控制
- SQL Server 2019+ 对标量 UDF 启用了“标量 UDF 内联”优化（需兼容级别 150+ 且函数满足条件），开启后性能可提升 10x+，但默认关闭
- 存储过程支持
SET NOCOUNT ON抑制影响行数消息，减少网络往返开销；函数完全不能发消息或改 SET 选项
事务边界在哪？函数里写 INSERT 会报错
用户定义函数（UDF）被设计为纯计算组件，SQL Server 明确禁止其修改数据库状态。一旦你在 CREATE FUNCTION 里写 INSERT、UPDATE、OPENQUERY 或调用含副作用的扩展存储过程，SQL Server 直接报错：Invalid use of a side-effecting operator 'INSERT' within a function.
- 存储过程天然运行在事务上下文中，可自由使用
BEGIN TRAN、COMMIT、ROLLBACK，也能嵌套调用其他存储过程并传播事务 - 函数只能读数据（
SELECT），且必须显式声明RETURNS TABLE或RETURNS @t TABLE才能返回多行；标量函数连SELECT都要加括号包装成表达式 - 跨数据库查询在函数中受限：不能用四部分命名（
db.schema.table）访问非当前库对象，除非用EXECUTE AS OWNER提权且目标库启用TRUSTWORTHY（不推荐）
参数传递和执行计划缓存差异极大
存储过程的执行计划按参数类型+值特征生成，SQL Server 会尝试参数化重用；而标量 UDF 的执行计划是“每个调用独立编译”的，哪怕参数值完全一样，只要调用位置不同（比如一个在 WHERE，一个在 SELECT 列表），就可能产生多个缓存条目。
- 存储过程支持输出参数（
@out INT OUTPUT），函数只能靠 RETURN 或表变量返回结果 - 表值函数（TVF）分两类：
INLINETVF 会被展开为视图式逻辑，参与查询优化器重写；MULTI-STATEMENTTVF 固定走临时表路径，常导致性能骤降 - 传 NULL 给存储过程参数，可能触发默认值逻辑；传 NULL 给标量函数，函数体里不做
IS NULL检查就直接运算，容易出NULL结果或隐式转换失败
什么时候必须用存储过程？别硬套函数
需要事务控制、动态 SQL、错误重试、多步骤状态维护、或调用 xp_cmdshell/sp_OACreate 等扩展功能时，函数完全无解。典型场景如：订单创建（扣库存+写日志+发消息）、批量导入校验（逐行检查+汇总错误）、跨服务器数据同步（OPENROWSET + 事务回滚）。
- 函数适合做“字段级计算”：格式化日期、脱敏手机号、计算折扣率——这些操作应无状态、无 IO、确定性返回
- 如果函数里开始写
WHILE循环、INSERT @t、IF EXISTS (SELECT...)，说明它已经越界，该重构成存储过程 - 注意：SQL Server 允许在函数中调用存储过程吗？答案是
NO，语法直接拒绝；反过来，存储过程中可以安全调用任意函数（包括你写的）
事务边界的混淆往往发生在把函数当“轻量过程”用，结果发现没法回滚、没法调试、没法监控执行时间——函数不是简化版存储过程，它是另一套契约。
