为啥使用 EF / Linq to sql 创建性能不佳的查询如此容易[关闭]

Posted 2023-04-12

【中文标题】为啥使用 EF / Linq to sql 创建性能不佳的查询如此容易[关闭]

【英文标题】：Why is it so easy to create bad performing queries with EF / Linq to sql [closed]为什么使用 EF / Linq to sql 创建性能不佳的查询如此容易[关闭]

【发布时间】：2013-08-29 07:08:56

【问题描述】：

我一直在使用 linq-to-sql 和 ado.net entityframework。每次我们遇到性能问题，几乎都是因为使用了 EF/linq to sql。编写代码似乎很容易，要么触发大量查询，要么首先获取 1000 条记录以在给出实际结果之前做一些内部工作。即使以我在这个问题上的知识和经验，我也经常发现自己使用某种逻辑 C# 语句会触发对数据库执行的非常不合逻辑的查询。

一个简单的例子：假设您有 2 个表 Customer 和 Invoices。 Invoice 在 Customer 表中有一个 CustomerID

这将首先从数据库中获取所有发票记录，然后检查是否有任何记录。如果您的客户有 1000 张发票，则会将 1000 条记录从数据库发送到您的应用程序

Customer.Invoices.Any() //or .Where or some paging statement or ...

这里的解决方法是直接在datacontext上查询

db.Invoices.Any(invoice=>invoice.CustomerID=Customer.CustomerID)

我确信总会有技术解释和解决问题的解决方案，但似乎很不合逻辑，以至于映射器很容易搞砸应用程序的性能。这些映射器非常简单，因此任何初级程序员都可以使用它，并承担所有后果。我见过一些或多或少有经验的开发人员甚至没有意识到这个问题。为什么我在谷歌上找不到任何关于这个“陷阱”的参考？我没有看到正确的道路吗？像 NHibernate 这样的其他 ORM 是否会遇到同样的问题？

【问题讨论】：

听起来好像您是根据最近的一些经验概括问题，而忽略了您遇到的其他问题，因为它们没有那么令人难忘。你的回答基本上是计算机只会做它被告知要做的事情

这确实是个问题。这是一个设计缺陷。我的解决方案：几乎从不使用集合导航属性。您很少需要所有子实体无序且根本不需要额外数据。它们没那么有用。

【参考方案1】：

这是所谓的对象关系阻抗失配的一部分。除了手动编写 SQL 代码之外，没有通用的解决方案。

http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

是的，所有的 ORM 都会在某种程度上受到这种影响。我见过的最好的方法是创建表示应该返回哪些数据的声明性指令的对象。只有在最后一刻才将所有指令组合成一条 SQL 语句来执行。我认为这基本上是 LINQ 已经在做的事情。

【讨论】：

我过去曾使用过 Linq-to-SQL，但从未遇到过必须手工制作 SQL 的情况。这并不是说没有必要的情况。但是，这对我来说似乎是一个过于笼统的答案。好像总是这样。

这不是本意。原来的帖子似乎在问为什么这个问题不能通过某种特定的方法神奇地解决。我的回答很简单，没有灵丹妙药。