存储过程 - 函数性能差异

我有一个表值函数，里面有相当多的代码，做多个连接选择和调用子函数并返回一个结果集。在开发此功能期间，在某些时候，执行该功能时我遇到性能下降。通常它不应该超过1秒，但它开始需要大约10秒。我玩了一些连接和索引，但没有什么变化。经过一段时间的变化和研究之后，我想用另一种方式看到结果。我创建了与存储过程具有相同确切参数的完全相同的代码。然后我执行了sp。繁荣！它需要少于1秒。相同的确切代码需要约10秒的功能。存储过程 - 函数性能差异

我真的不知道这一切是什么，我没有时间做更多的研究。由于某些原因，我需要它作为函数，但我不知道现在要做什么。我以为我可以创建它作为一个过程，然后在函数内调用它，但后来我意识到它不可能为函数执行它。

我想从专家那里听到一些好的意见和建议。在此先感谢

ps：我没有添加任何代码，因为代码不是很好的格式和很脏。如果有人感兴趣，我会分享它。服务器是SQL 2014年企业64位编辑：我看到可能重复的问题之前，但它不满足我，因为我的问题是具体关于性能问题。另一个问题有许多关于程序和功能之间差异的答案。我想更清楚地说明可能的性能相关差异。

来源

2015-07-02 Mehmet Hulusi Akyıl

存储过程缓存执行计划并且用户定义函数不会，因此存储过程的性能更好。 Google'SQL Server存储过程执行计划'，你会学到很多东西。 –

[函数vs存储过程]的可能重复（http://stackoverflow.com/questions/178128/functions-vs-stored-procedures） –

正如@ M.Ali所述，多语句表函数不会存储执行计划，而存储过程呢。查看[函数vs存储过程]中的链接和讨论主题（http://stackoverflow.com/questions/178128/functions-vs-stored-procedures） –

这些都是从我的经验的差异：

当你第一次开始写的功能，你很可能直到它正常使用相同的参数重新&再次运行。这使得SQL Server可以将相关数据保存在内存中的页面缓存。
函数不会缓存它们的执行计划。随着您添加更多数据，制定计划需要更长的时间。 SET STATISTICS TIME ON查看查询编译时间与执行时间。
功能只能使用表变量，并没有统计这些。这可能会在稍后做出一些可怕的决定。

有些人喜欢表值函数，因为它们更容易查询：

SELECT * FROM fcn_myfunc(...) WHERE <some_conditions>

而不是创建一个临时表中，执行的是存储过程，然后过滤掉该临时表。如果您的代码对性能至关重要，请将其转换为存储过程。

来源

2015-07-03 01:51:30

SQL Server分析和编译时间： CPU时间= 0毫秒，经过时间= 0毫秒。 SQL Server执行时间： CPU时间= 0毫秒，经过时间= 0毫秒。（5行受影响） SQL Server执行时间： CPU时间= 12531毫秒，经过时间= 13106毫秒。这是否有任何意义？ –

存储过程 - 函数性能差异

回答

相关问题