我目前的项目是一个大型公共站点（每天200万页面浏览量）网站，运行asp经典和asp.net与SQL Server 2005后端的混合。我们读取很多，偶尔写入并且几乎没有更新/删除。我们的页面通常涉及具有一堆依赖（细节）对象的单个“主”对象。
我喜欢在单个proc中返回页面所需的所有数据的想法（绝对没有不必要的数据）。没错，这需要对这些页面进行专门的处理，但是有些页面会获得我们整体网站流量的两位数百分比，因此值得花时间/维护。我们通常只使用System.Data.SqlClient.SqlDataReader和它的NextResult方法从我们的.net代码中使用多记录集。哦，是的，我没有在这些过程中进行任何更新/插入（表变量除外）。
到目前为止，SQL Server（2005）处理哪些返回多个记录集对我们来说运行良好（在prod中）但是我有点担心多记录集触发器是我最喜欢的锤子，我正在遇到每个问题（指甲）。有没有我应该知道的多记录集sql server proc gotchas？什么东西会让我希望我没有使用它们？特别是它影响连接池，内存利用率等的任何事情。
以下是多记录集存储过程的一些问题：
它们使重用代码变得更加困难。如果您正在进行多次查询，则可能会在其他页面上重复使用其中一个查询。
它们使单元测试变得更加困难。每次对其中一个查询进行更改时，都必须测试所有结果。如果发生了变化，您必须深入了解哪个查询未通过单元测试。
它们使得以后调整性能变得更加困难。如果有另一个DBA来帮助提高性能，他们必须做更多的切片和切块来找出问题的来源。然后，将其与代码重用问题相结合 - 如果它们优化了一个查询，那么该查询可能会在几个不同的存储过程中使用，然后他们必须修复所有这些 - 这样可以再次进行更多的单元测试。
它们使错误处理变得更加困难。存储过程中的四个查询可能会成功，第五个查询失败。你必须为此做好计划。
它们可能会增加锁定问题并导致TempDB中的负载。如果您的存储过程以一种需要重复读取的方式设计，那么您在存储过程中填充的查询越多，运行所需的时间就越长，将这些结果返回给您的应用服务器所需的时间就越长。增加的时间意味着更高的锁争用，并且SQL Server必须存储在TempDB中以进行行版本控制。你提到你对阅读很重要，所以这个特殊的问题对你来说不应该太糟糕，但你想在重写密集的应用程序上重用这个锤子之前要注意它。
我认为多记录集存储过程在某些情况下很棒，听起来像你的其中之一。
您的网站越大（流量越多），“额外”的性能就越重要。如果你可以将2-3-4个调用（可能还有一个新的连接）组合到一个数据库中，那么你每天可以减少4-6-8百万次数据库命中，这是非常重要的。
我谨慎地使用它们，但是当我拥有它时，我从来没有遇到过问题。
我建议在一个存储过程中调用几个内部调用的存储过程，每个调用返回1个resultset。
create proc foo
as
execute foobar --returns one result
execute barfoo --returns one result
execute bar --returns one result
这样，当需求发生变化并且您只需要第3和第5个结果集时，您可以轻松地调用它们而无需添加新的存储过程并重新生成数据访问层。如果我需要，我当前的应用程序将返回所有参考表（例如美国州表）。最糟糕的是当你需要获取一个引用表时，唯一的访问是通过一个存储过程，该存储过程也运行一个昂贵的查询作为其六个结果集之一。