我有一个 ADO.NET/TSQL 性能问题。我们的应用程序有两个选项：
1) 一个带有多个结果集的大型数据库调用，然后在代码中逐步遍历每个结果集并填充我的对象。这会导致数据库往返一次。
2) 多个小型数据库调用。
选项 2 有更多的代码重用，这是该选项的一个优势。但我想了解一下性能成本是多少。两次小的往返是数据库的一次大往返的两倍慢，还是只是很小的，比如 10% 的性能损失？我们使用带有存储过程和 ADO.NET 的 C# 3.5 和 Sql Server 2008。
【问题讨论】：
标签： tsql
我认为这部分取决于您何时需要数据。例如，如果您在一个大型流程中返回十个数据集，并且一次在屏幕上看到所有十个数据集，那么就去做吧。但是，如果您返回十个数据集，而用户可能只点击页面查看其中三个，那么发送其他数据集是对服务器和网络资源的浪费。如果您返回 10 个数据集，但用户确实需要在更改第 5 组和第 6 组后查看第 7 组和第 8 组，那么如果您返回得太早，用户会看到错误的信息。
如果您为在一个主存储过程中调用的每个数据集使用单独的存储过程，那么您完全没有理由不能在其他地方重用代码，因此代码重用在我看来并不是一个真正的问题。
【讨论】：
这听起来有点明显，但只需一次调用即可发送您需要的内容。
例如，我们有一个用于演示的“getStuff”存储过程。 “updateStuff”过程调用“getStuff”过程，“updateStuff”的客户端包装方法需要类型“Thing”。所以来回一趟。
喋喋不休的服务器是您以最小的努力预先阻止的一件事。然后，您可以根据需要调整数据库或客户端代码......但是无论您的代码运行多快，以后都很难排除往返。在极端情况下，如果您的 Web 服务器与您的数据库服务器位于不同的国家/地区怎么办...？
编辑：有趣的是注意到 SQL 人员（HLGEM、asstander、我）说“一次旅行”而客户人员说“多次，代码重用”...
【讨论】：
我自己也在努力解决这个问题。我还没有答案，但我确实有一些想法。
回顾了其他人对此给出的答案，还有第三种选择。
在我的应用程序中，大约有十到十二次调用服务器来获取我需要的数据。一些数据字段是 varchar max 和 varbinary max 字段（图片、大型文档、视频和声音文件）。我所有的调用都是同步的——即，在请求数据时，用户（和客户端程序）别无选择，只能等待。他可能只想阅读或查看只有在全部存在时才完全有意义的数据，而不仅仅是部分存在。我相信，这个过程会更慢，我正在开发一种替代方法，该方法基于从 DLL libaray 对服务器的异步调用，该 DLL libaray 向客户端引发事件以向客户端宣布进度。客户端被编程为处理 DLL 事件并在客户端设置一个变量，指示 chich 调用已完成。然后，客户端程序可以做它必须做的事情来准备在调用 #1 中接收到的数据，而 DLL 正在异步进行以获取调用 #2 的数据。当客户端准备好处理调用#2 的数据时，它必须检查状态并在必要时等待继续（我希望这将是一个短暂的等待或根本没有等待）。通过这种方式，服务器端和客户端软件都能以更高效的方式完成工作。
【讨论】：
如果您非常关心性能，请尝试对两者进行测试，看看哪个性能更好。
就个人而言，我更喜欢第二种方法。它使开发人员的生活更轻松，使代码更易于重用，并将事物模块化，因此更容易进行更改。
【讨论】：
我个人喜欢选项二，原因是您所说的：代码重用
但请考虑一下：对于小请求，延迟可能比您对请求所做的要长。你必须找到正确的平衡点。
【讨论】：
作为 ADO.Net 开发人员，您的工作是使代码尽可能正确、清晰和可维护。这意味着您必须将关注点分开。
SQL Server 连接技术的工作是使其快速。
如果您实现了一个正确、清晰、可维护的应用程序来解决业务问题，而事实证明数据库访问是阻止系统在可接受的范围内运行的主要瓶颈，那么，只有这样，您才应该开始寻找解决问题的方法。这可能包括也可能不包括合并数据库查询。
【讨论】：
在需要之前不要优化性能。这意味着您应该分析您的预期使用模式，并确定此过程的典型使用频率是多少，以及当前设计会导致什么用户界面延迟。如果用户收到来自应用程序的反馈少于几 (2-3) 秒，并且此过程的应用程序负载不是服务器容量的过度负载，则不必担心。如果用户等待响应的时间过长（主观但绝对可测量），或者服务器超载，那么是时候开始优化了。然后，哪种优化技术最有意义或最具成本效益，取决于您对问题的分析告诉您什么。
因此，与此同时，请关注可维护性。这意味着，在您的情况下，代码重用
【讨论】：
我个人会选择更大的往返行程。
这肯定会受到调用代码的确切可重用性以及重构方式的影响。
但如前所述，这将取决于您的具体情况，其中可维护性与性能可能是一个因素。
【讨论】：