存储过程比函数快或不

我使用存储过程的时刻，但我有一个这样的东西很多：存储过程比函数快或不

if ... begin select 'success' return end 
if ... begin select 'notgood' return end 
if ... begin select 'someelse' return end

所以我想，这将是一个更好的主意，用函数来代替，但函数和存储过程之间是否存在任何性能差异？

来源

2009-12-30 Omu

什么数据库？与简单表达式相比，MySQL存储例程，函数以及存储过程非常缓慢。也就是说，如果大部分时间都花在等待数据库IO上，那么这可能不是问题。 – 2009-12-30 09:46:28

它通常取决于你的情况。找出最好的方法是制定一个小型的基准程序，看看哪个性能更好。 – 2009-12-30 09:47:02

我正在使用MSSQL – Omu 2009-12-30 09:47:57

通常，跨平台应该没有太大的区别（我假设你在这里指的是SQL Server），因为它应该是相同的操作;查找存储过程/函数，编译如果需要等等等等。

我知道SQL Server中的函数可以在CREATE FUNCTION语句中声明SCHEMABINDING，这会使您获得一些性能上的提升，代价是在创建函数时锁定到模式。

来源

2009-12-30 09:46:15 casperOne

要说明您的情况的最好方法是设置一些测试，运行它们并比较结果。这不是一个警察答案：为自己进行测试确实是最好的告诉方式。要考虑您的独特情况有很多因素 - 例如数据库平台，服务器硬件，网络延迟，业务/客户端应用层，不同时间的服务器/网络负载等。

来源

2009-12-30 10:07:28

如何以及在哪里使用该功能。例如，从SELECT语句的WHERE子句调用的函数可能是性能杀手。我们曾经有过类似的表述：

SELECT * FROM TRANSACTIONS T 
    WHERE IS_UGLY_TRANSACTION_CODE(T.TRANSACTION_CODE) = 'T' AND ...

整体运行进程的方式过于缓慢和安装日期是我们前进的道路太快，所以我开始插装的代码来找出其中的时间要去。当我收到分析报告时，我看了看它，发现这项工作处理了1000个事务，然后注意到IS_SALES_TRANSACTION被称为大约50万次。经过一番思考和对语句执行计划的一些研究之后，我意识到数据库正在将该例程用作查询中的主要过滤器，并且这导致了两件不好的事情发生：首先，存在查询中的例程阻止了索引的使用，因此查询正在扫描该表，其次在扫描过程中正在调用表中每一行的例程。使用TRANSACTION_CODE列上的等效检查替换函数调用会将运行时间从15分钟降低到5秒。

来源

2009-12-30 11:52:57

存储过程比函数快或不

回答

相关问题