随着时间的推移，SQL Server缩小了UDF与存储过程之间的差距。很多时候，你会使用其中一种。经验法则是函数做一个特定的事情（getdate（）），而过程通常做多件事 - 很多次，复杂的业务逻辑（sp_addarticle）。
我们的开发团队已经创建了数百个功能，这些功能确实会导致性能问题。无论函数返回多少行，执行计划都会将它们视为返回一行。这导致了性能问题。每当有瓶颈时，我们只需将功能转换为Procs！这种方法正在成为一种趋势。
我知道以这种或那种方式有利有弊吗？我有几个问题：
将所有功能转换为过程是否有任何负面影响？ （这将是一个艰巨的任务！但我们可能不得不咬那个 bullet。）
是否只能在功能中实现？ （我知道 只有UDF才有。对于例如你可以调用一个函数 SELECT或函数可以在DEFAULTS中引用。我不是在找 这样的事情。）
数据库中的最大UDF数是多少？ （只是 好奇。）
答案 0 :(得分：1)
这是一个复杂的问题，没有确切的答案（也许你应该在Quora上发布）但我会尝试......
SELECT * FROM MyStoredProcedure我没有看到任何负面的事实......另一方面，你可能会获得安全性，因为SP必须由EXEC mySP调用，而USF不是，所以如果一个开发人员给USF命名像“LastYearOrders”这样的人可能会认为它是一张桌子......这也使得一个破解工作变得更容易...... 答案 1 :(得分：1)
这个问题中的一些确实转向了大量基于意见的信息，但这就是我所说的（试图远离个人观点）：
顺便说一句，您是否尝试在函数定义中使用WITH SCHEMABINDING？如果适用，这可以提高性能。
答案 2 :(得分：0)
一个原因是能够在计算列中使用UDF。我想另一个是使用标量值函数的能力。
批量转换所有UDF听起来像是一个膝跳反应。您是否确定了性能问题的根本原因？是否有比垃圾邮件更适合作为UDF的UDF？