多个结果集与多个性能调用

本文关键字：性能 调用 结果 | 更新日期: 2023-09-27 18:35:34

我正在开发一个相当高性能的应用程序，我知道数据库连接通常是更昂贵的操作之一。我有一个运行非常频繁的任务，在业务过程中，它必须从表 1 和表 2 中选择数据。我有两个选择：

  1. 继续像我现在一样进行两个实体框架查询。 从表 1 中进行选择，然后从 linq 查询中的表 2 中进行选择。（我现在在做什么）。

  2. 创建了一个存储过程，该过程使用多个结果集在一个查询中返回两个结果集。

我想SQL Server的成本是相同的：正在执行相同的IO。我很好奇是否有人可以谈论毫秒很重要的"热"代码路径中可能存在的性能提升。

多个结果集与多个性能调用

我知道数据库连接通常是更昂贵的操作之一

除非关闭连接池，

否则只要池中已建立连接并可供使用，获取连接就非常便宜。反正这里也真的无关紧要。

当涉及到两个查询（无论是否为 EF）与一个具有两个结果集的查询（并在数据读取器上使用NextResult）时，您将获得一点收益，但实际上并不多。由于无论哪种方式都不需要重新建立连接，因此一个开销相对于另一个开销的减少非常小，如果结果足够大，以至于您非常关心这种影响，那么与实际数据量相比，这将相形见绌。（如果可以合并两个结果集，则开销会减少，但无论如何也可以使用 EF 执行此操作）。

如果您的意思是建立连接后通过连接来回传输的字节数，那么您应该能够向数据库发送的字节略少（但我们谈论的是几个字节），并且返回的内容大致相同，假设您的查询只是获取实际需要的内容。也就是说，如果您需要 id 和名称，而不是为每一行拉回完整的实体，您可以执行类似 from t in Table1Repository select new {t.ID, t.Name} 的操作。

EntityFramework做了很多事情，做任何事情都需要成本，所以自己承担更多的工作应该意味着你可以更严格。但是，除了引入新的错误范围而不是经过尝试和测试的范围之外，您还引入了新的范围，以比 EF 效率低。

任何在不同数据库处理代码之间寻求共性的做法都会使您在最终生成自己的 EntityFramework 版本的路径上走得更远，但所有这些代码的效率都取决于您。任何简化特定查询的尝试都会使您陷入与拥有大量相似但不完全相同的代码相反的方向，这些代码的错误和性能影响略有不同。

总之，最好先采用 EF 方法，如果特定查询在性能方面证明特别麻烦，那么首先看看是否可以在保留 EF 的同时对其进行改进（优化 linq，在适当时使用AsNoTracking等等），如果它仍然是一个热点，请尝试使用 ADO 手动滚动该部分和度量。在那之前，说"是的，将两个结果集与 ADO.NET 一起使用会稍微快一些"并不是非常有用，因为"稍微"取决于什么。

如果查询是从表 1 和 table2 中读取的简单查询，则 LinQ 查询应提供与执行存储过程（纯 SQL）类似的性能。但是，如果查询跨不同的数据库运行，那么纯SQL总是更好，您可以在其中合并结果集并获取来自所有数据库的数据。在MySQL中"解释"语句可以用来知道查询的性能。请参阅此链接：http://www.sitepoint.com/using-explain-to-write-better-mysql-queries/另一个有用的工具是在 Visual Studio 的输出窗口中检查为 LinQ 查询生成的 SQL，Microsoft。您可以直接在 SQL 编辑器中执行此查询并检查性能。

相关文章：