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