我正在开发一个性能相当高的应用程序，我知道数据库连接通常是更昂贵的操作之一 . 我有一个经常运行的任务，并且在业务过程中它必须从Table1和Table2中选择数据 . 我有两个选择：
-
继续像我现在一样制作两个实体框架查询 . 从Table1中选择并从linq查询中的Table2中选择 . （我现在正在做什么） .
-
创建了一个存储过程，该过程使用多个结果集在一个查询中返回两个结果集 .
我想象SQL Server的成本是相同的：正在执行相同的IO . 我很好奇是否有人能说出在毫秒重要的“热”代码路径中可能存在的性能冲击 .
2 回答
除非您关闭连接池，否则只要池中已 Build 连接并且可以使用，获取连接就相当便宜 . 无论如何，这也无所谓 .
当涉及到两个查询（无论是否为EF）与一个具有两个结果集的查询（以及在数据读取器上使用
NextResult）时，您将获得一点，但实际上并不多 . 由于只有一个在另一个上方的开销只有非常小的减少，如果结果足够大，你可能会非常关心这种影响，那么实际数据的数量会相形见绌 . （如果你可以结合两个结果集，那么再次减少开销，但是无论如何你也可以用EF做到这一点） .如果你的意思是字节在连接之后一遍又一遍地通过连接来讨论一些字节）并且大致相同的回来，假设你的查询只是获得实际需要的东西 . 如果您需要ID和名称而不是为每一行拉回完整实体，那么您可以执行类似_1520151的操作 .
EntityFramework做了很多事情，做了任何事情，所以自己承担更多的工作应该意味着你可以更加紧张 . 然而，除了在试验和测试中引入新的错误范围之外，您还引入了比EF更低效的新范围 .
任何寻求不同数据库处理代码之间的共性都会让你越来越沿着最终生成自己的EntityFramework版本的路径，但所有这些都取决于你的效率 . 任何简化特定查询的尝试都会带来与大量相似但不完全相同的代码相反的方向，这些代码具有略微不同的错误和性能命中 .
总而言之，你可能最好先采用EF方法，如果特定查询在性能方面证明特别麻烦，那么首先看看你是否可以在保留EF时进行改进（优化linq，在适当时使用
AsNoTracking等等）如果它仍然是一个热点，那么尝试用ADO手动滚动该部分并进行测量 . 在那之前，说"yes, it would be slightly faster to use two resultsets with ADO.NET"并不是非常有用，因为"slightly"取决于它 .如果查询是从table1和table2读取的简单查询，那么LinQ查询应该提供与执行存储过程（纯SQL）相似的性能 . 但是如果查询在不同的数据库中运行，那么普通的SQL总是更好，在这里你可以联合结果集并拥有所有数据库中的数据 . 在MySQL "Explain"语句中可以用来了解查询的性能 . 请参阅此链接：http://www.sitepoint.com/using-explain-to-write-better-mysql-queries/另一个有用的工具是检查在Microsoft Visual Studio的输出窗口中为LinQ查询生成的SQL . 您可以直接在SQL编辑器中执行此查询并检查性能 .