<分区>
我正在开发一个相当高性能的应用程序，而且我知道数据库连接通常是比较昂贵的操作之一。我有一个运行很频繁的任务，在业务过程中它必须从表 1 和表 2 中选择数据。我有两个选择:
继续像我现在这样进行两个 Entity Framework 查询。在 linq 查询中从 Table1 中选择并从 Table2 中选择。 (我现在正在做的事情)。
创建了一个存储过程，该过程使用多个结果集在一个查询中返回两个结果集。
我想 SQL Server 的成本是相同的:正在执行相同的 IO。我很好奇是否有人可以谈论毫秒级的“热”代码路径中可能存在的性能提升。
最佳答案
and I know database connections are usually one of the more expensive operations
除非您关闭连接池，否则只要池中已经建立了连接并且可以使用，获取连接的成本就非常低。无论如何，这在这里也不重要。
当涉及到两个查询(无论是否为 EF)与具有两个结果集的一个查询(并在数据读取器上使用 NextResult)时，您会获得一点，但实际上不会太多。由于无论哪种方式都不需要重新建立连接，因此两者之间的开销只有非常小的减少，如果结果足够大以至于您非常关心，那么与实际数据量相比，这将相形见绌这种影响。 (如果您可以合并这两个结果集，开销会再次减少，但无论如何您也可以使用 EF 做到这一点)。
如果你的意思是字节在连接建立后来回移动，那么你应该能够向数据库发送稍微少一点的数据(但我们说的是少量字节)并且同样回来，假设您的查询仅获得实际需要的内容。也就是说，如果您需要 ID 和名称，而不是为每一行拉回完整的实体，您可以执行类似 from t in Table1Repository select new {t.ID, t.Name} 的操作。
EntityFramework 做一大堆事情，做任何事情都要付出代价，所以你自己承担更多的工作应该意味着你可以更紧凑。但是，除了在久经考验的情况下引入新的错误范围外，您还引入了比 EF 效率低下的新范围。
任何在不同的数据库处理代码之间寻求共性的做法都会让您在最终生成您自己的 EntityFramework 版本的路径上越走越远，但所有这一切的效率都取决于您。任何简化特定查询的尝试都会让您走向相反的方向，即拥有大量相似但不完全相同的代码，但错误和性能影响略有不同。
总而言之，您最好先采用 EF 方法，如果特定查询证明在性能方面特别麻烦，那么首先看看您是否可以在继续使用 EF 的同时改进它(优化 linq，使用 AsNoTracking 在适当的时候等等)，如果它仍然是一个热点，那么尝试使用 ADO 手动滚动该部分并进行测量。在那之前，说“是的，使用 ADO.NET 的两个结果集会稍微快一些”并不是很有用，因为“稍微”取决于什么。
关于c# - 多个结果集与多个性能调用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27682825/