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

Question

我正在开发一个性能相当高的应用程序,我知道数据库连接通常是更昂贵的操作之一.我有一个经常运行的任务,并且在业务过程中它必须从Table1和Table2中选择数据.我有两个选择:

1. 像我一样继续制作两个实体框架查询.从Table1中选择并从linq查询中的Table2中选择.(我现在正在做什么).

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

我想象SQL Server的成本是相同的:正在执行相同的IO.我很好奇是否有人能说出在毫秒重要的"热"代码路径中可能存在的性能冲击.

Answer 1

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

除非您关闭连接池,否则只要池中已建立连接并且可以使用,获取连接就相当便宜.无论如何,这也无所谓.

当涉及两个查询(无论是否为EF)与一个具有两个结果集的查询(以及NextResult在数据读取器上使用)时,您将获得一点,但实际上并不多.由于不需要以任何方式重新建立连接,因此只有非常小的一个开销减少,如果结果大到足以让您关心很多,那么实际数据的数量会相形见绌.这种影响.(如果你可以结合两个结果集,那么再次减少开销,但是无论如何你也可以用EF做到这一点).

如果你的意思是在建立之后连接上下来的字节,那么你应该能够稍微向数据库发送(但我们正在谈论一些字节)并且大致相同的回来,假设你的查询只获取实际需要的内容.也就是说,from t in Table1Repository select new {t.ID, t.Name}如果你需要id和名称而不是为每一行拉回完整的实体,你就会做一些事情.

EntityFramework做了很多事情,做了任何事情,所以自己承担更多的工作应该意味着你可以更加紧张.然而,除了在试验和测试中引入新的错误范围之外,您还引入了比EF更低效的新范围.

任何寻求不同数据库处理代码之间的共性都会让你越来越沿着最终生成自己的EntityFramework版本的路径,但所有这些都取决于你的效率.任何简化特定查询的尝试都会带来与大量相似但不完全相同的代码相反的方向,这些代码具有略微不同的错误和性能命中.

总而言之,你可能最好先采用EF方法,如果某个特定查询在性能方面证明特别麻烦,那么首先看看你是否可以在保留EF时进行改进(优化linq,AsNoTracking在适当的时候使用等等) )如果它仍然是一个热点,那么尝试用ADO手动滚动该部分并进行测量.在那之前,说"是的,在ADO.NET中使用两个结果集会稍微快一点"并不是非常有用,因为这只是"略微"取决于它.