在SQL中什么时候应该使用函数而不是存储过程,反之亦然?每一个的目的是什么?


当前回答

存储过程用作脚本。它们为您运行一系列命令,您可以安排它们在特定时间运行。通常运行多个DML语句,如INSERT, UPDATE, DELETE等,甚至是SELECT。

函数用作方法。你给它传递一些东西,它会返回一个结果。应该是小而快速的-在飞行中。通常在SELECT语句中使用。

其他回答

函数是计算值,不能对SQL Server执行永久的环境更改(即不允许INSERT或UPDATE语句)。

如果函数返回标量值,则可以在SQL语句中使用它;如果函数返回结果集,则可以连接它。

从总结答案的评论中,有一点值得注意。感谢@Sean K Anderson:

函数遵循计算机科学的定义,即它们必须返回一个值,并且不能更改作为参数接收的数据 (论点)。函数不允许改变任何东西,必须 至少有一个参数,并且它们必须返回一个值。存储 Procs不需要有参数,可以改变数据库对象, 并且不需要返回值。

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

函数可以是…

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

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

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

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


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

一般来说,使用存储过程的性能更好。 例如,在以前版本的SQL Server中,如果你将函数置于JOIN条件下,基数估计为1 (SQL 2012之前)和100 (SQL 2012之后和SQL 2017之前),引擎可能会生成一个糟糕的执行计划。

此外,如果你把它放在WHERE子句中,SQL引擎可能会生成一个糟糕的执行计划。

在SQL 2017中,微软引入了称为交错执行的功能,以产生更准确的估计,但存储过程仍然是最佳解决方案。

要了解更多细节,请参阅以下Joe Sack的文章 https://techcommunity.microsoft.com/t5/sql-server/introducing-interleaved-execution-for-multi-statement-table/ba-p/385417

当你想要计算并返回一个值以供其他SQL语句使用时,编写一个用户定义函数;当您想要编写存储过程时,您可以将一组可能很复杂的SQL语句分组。毕竟,这是两个非常不同的用例!

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

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

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