我知道，这个问题已经讨论过好几次了(大多数讨论都是在几年前…)。
但是，通过这些讨论，我得到的感觉是，有一个广泛传播的常识是完全错误的:电视udf在性能上很差。
很多人喜欢用SPs来收集数据，为什么?
当我说TV-UDF时，我指的是单语句- udf ("Inline-UDF")。优化器将巧妙地处理这个问题，就像直接将这部分写入查询一样。多语句udf的性能更差…从我的角度来看，为什么你几乎永远都应该使用UDF来收集数据，我看到了以下几点:
- 最佳性能(我做了很多比较!)
- 您可以轻松地将它们与JOIN或APPLY一起使用，并获得非常复杂但仍然可读的查询(我使用一个由30多个函数组成的"univers"查询，其中包含1000多个列-在几秒钟内!)
- 你可以从任何地方调用它们(例如，通过ODC调用一个excel表格)
- 您可以将它们与xml调用完美地混合使用
- 如果你的选择只需要列的一个子集，优化器将跳过不需要的部分-而不是SP
- 使用内联udf，优化器可以预测行数，并能够使用索引、统计信息等所有功能。SP 则不是这样
- 使用内联udf，当您希望使用后一个 中的数据时，不需要为插入编写整个表定义。
- 您可以用
Select count(*) from(select * from dbo.MyFunc())"包装"UDF以预测行数。优化器将只执行获得计数所需的部分… - 并且-最后但并非最不重要的-由于UDF从不写入任何内容，因此在锁定 方面要轻得多
当结果在任何情况下都是一个不同的行时，我使用多语句udf，当需要游标或动态sql时(这是非常罕见的)，我使用sp。
那么:为什么这么多人使用sp来收集数据?为什么这么多人认为udf不好呢?有什么好的理由吗，或者这只是老常识?
谢谢你的意见!
我认为你是在比较苹果和橙子，至少我从未见过任何关于这方面的讨论。有关于是否应该使用udf的讨论，也有关于是否应该使用存储过程或特殊SQL的讨论。
内联UDF是可以在查询中使用的东西，而存储过程是可以执行的东西，您的大多数要点都是这种差异的结果。
内联UDF更像是一个视图，而不是存储过程。可以在查询中使用的参数化视图，有时可以用来加快速度。
最佳表现(我做了很多比较!)
我非常希望看到这样一个场景:内联UDF和存储过程做同样的事情，但性能不同。
并且-最后但并非最不重要的-因为UDF从不写入任何内容，所以它是更轻的锁定
如果存储过程从不写任何东西，那么锁定就没有区别。
那么:为什么这么多人使用sp来收集数据?
不了解其他人，但对我来说，这都是关于存储过程与临时sql的讨论。我更喜欢存储过程，而不是特别喜欢。如果你想使用用户定义的函数而不是过程的，你最终会进入ad hoc sql阵营。