任何SQL Server多记录集存储过程都有问题？

Question

上下文

我目前的项目是一个大型公共站点(每天200万页面浏览量)网站,运行asp经典和asp.net与SQL Server 2005后端的混合.我们读取很多,偶尔写入并且几乎没有更新/删除.我们的页面通常涉及具有一堆依赖(细节)对象的单个"主"对象.

我喜欢在单个proc中返回页面所需的所有数据的想法(绝对没有不必要的数据).没错,这需要对这些页面进行专门的处理,但是有些页面会获得我们整体网站流量的两位数百分比,因此值得花时间/维护.我们通常只使用System.Data.SqlClient.SqlDataReader和它的NextResult方法从我们的.net代码中使用多记录集.哦,是的,我没有在这些过程中进行任何更新/插入(表变量除外).

这个问题

到目前为止,SQL Server(2005)处理哪些返回多个记录集对我们来说运行良好(在prod中)但是我有点担心多记录集触发器是我最喜欢的锤子,我正在遇到每个问题(指甲).有没有我应该知道的多记录集sql server proc gotchas？什么东西会让我希望我没有使用它们？特别是它影响连接池,内存利用率等的任何事情.

Answer 1

以下是多记录集存储过程的一些问题:

它们使重用代码变得更加困难. 如果您正在进行多次查询,那么您可以在其他页面上重复使用其中一个查询.

它们使单元测试变得更加困难. 每次对其中一个查询进行更改时,都必须测试所有结果.如果发生了变化,您必须深入了解哪个查询未通过单元测试.

它们使得以后调整性能变得更加困难. 如果有另一个DBA来帮助提高性能,他们必须做更多的切片和切块来找出问题的来源.然后,将其与代码重用问题相结合 - 如果它们优化了一个查询,那么该查询可能会在几个不同的存储过程中使用,然后他们必须修复所有这些 - 这样可以再次进行更多的单元测试.

它们使错误处理变得更加困难. 存储过程中的四个查询可能会成功,第五个查询失败.你必须为此做好计划.

它们可能会增加锁定问题并导致TempDB中的负载. 如果您的存储过程以一种需要重复读取的方式设计,那么您在存储过程中填充的查询越多,运行所需的时间就越长,将这些结果返回给您的应用服务器所需的时间就越长.增加的时间意味着更高的锁争用,并且SQL Server必须存储在TempDB中以进行行版本控制.你提到你对阅读很重视,所以这个特殊的问题对你来说不应该太糟糕,但是你想要在一个写密集型应用程序上重用这个锤子之前要注意它.

Answer 2

我认为多记录集存储过程在某些情况下很棒，听起来您可能是其中之一。

您的网站越大（流量越多），“额外”的性能就越重要。如果您可以将 2-3-4 次调用（可能还有一个新连接）与数据库合二为一，您每天可以将数据库点击量减少 4-6-8 百万次，这是非常可观的。

我很少使用它们，但是当我使用它们时，我从来没有遇到过问题。