要决定何时使用以下几点可能会有所帮助-

存储过程不能返回表变量，而函数可以这样做。 您可以使用存储过程来更改服务器环境参数，而使用函数则不能。

干杯

函数可以在选择语句中使用，而过程则不能。 存储过程同时接受输入和输出参数，而函数只接受输入参数。 函数不能返回text, ntext, image和时间戳类型的值，而过程可以。 函数可以在创建表中作为用户定义的数据类型使用，但过程不能。

***例如:-create table <tablename>(name varchar(10)，salary getsal(name))

这里getsal是一个用户定义的函数，它返回一个工资类型，当创建表时，没有存储空间分配给工资类型，getsal函数也不执行，但当我们从这个表中获取一些值时，getsal函数get被执行，返回 类型作为结果集返回。

我知道这是一个非常老的问题，但是我在任何答案中都没有看到一个关键的方面:内联到查询计划中。

函数可以是…

标量: 创建函数…返回scalar_type AS BEGIN…结束 Multi-statement表值: 创建函数…返回@r表(…)开始…结束 内联表值: 创建函数…返回表作为return select…

第三种(内联表值)被查询优化器本质上视为(参数化)视图，这意味着从查询中引用函数类似于复制粘贴函数的SQL主体(而不是实际的复制粘贴)，导致以下好处:

查询计划器可以优化内联函数的执行，就像它会优化任何其他子查询一样(例如，消除未使用的列，下推谓词，选择不同的JOIN策略等)。 组合几个内联函数并不需要在将第一个函数的结果提供给下一个函数之前实现它。

上述方法可能会带来潜在的显著性能节省，特别是在组合多个级别的功能时。

注意:看起来SQL Server 2019也将引入某种形式的标量函数内联。

这里有一个更喜欢函数而不是存储过程的实际原因。如果有一个存储过程需要另一个存储过程的结果，则必须使用insert-exec语句。这意味着您必须创建一个临时表并使用exec语句将存储过程的结果插入到临时表中。它是混乱的。这样做的一个问题是insert-execs不能嵌套。

如果您使用调用其他存储过程的存储过程，可能会遇到这种情况。如果嵌套存储过程只是返回一个数据集，则可以将其替换为表值函数，这样就不会再出现此错误。

(这是我们应该将业务逻辑排除在数据库之外的另一个原因)

函数和存储过程有不同的用途。虽然这不是最好的类比，但函数可以从字面上视为任何编程语言中使用的任何其他函数，但存储的proc更像是单个程序或批处理脚本。

函数通常有一个输出和可选的输入。输出可以作为另一个函数的输入(SQL Server内置的，如DATEDIFF, LEN等)或作为SQL查询的谓词-例如，SELECT a, b, dbo.MyFunction(c) FROM表或SELECT a, b, c FROM表WHERE a = dbo.MyFunc(c)。

Stored proc用于将SQL查询绑定到事务中，并与外部世界进行交互。框架，如ADO。NET等不能直接调用函数，但可以直接调用存储过程。

函数确实有一个隐患:它们可能被误用并导致相当严重的性能问题:考虑以下查询:

SELECT * FROM dbo.MyTable WHERE col1 = dbo.MyFunction(col2)

其中MyFunction声明为:

CREATE FUNCTION MyFunction (@someValue INTEGER) RETURNS INTEGER
AS
BEGIN
   DECLARE @retval INTEGER

   SELECT localValue 
      FROM dbo.localToNationalMapTable
      WHERE nationalValue = @someValue

   RETURN @retval
END

这里发生的事情是，MyFunction函数被MyTable表中的每一行调用。如果MyTable有1000行，那么就有另外1000个针对数据库的特别查询。类似地，如果函数在列规范中指定时被调用，则该函数将对SELECT返回的每一行被调用。

所以写函数的时候一定要小心。如果从函数中的表执行SELECT操作，则需要问问自己，在父进程中使用JOIN或其他SQL构造(如CASE…当……其他的……结束)。