c# - 为什么使用 EF/Linq to sql 创建性能不佳的查询如此容易

标签 c# performance entity-framework linq-to-sql orm

<分区>

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

一个简单的例子:假设您有 2 个表 Customer 和 Invoices。发票有一个 CustomerID 到 Customer 表

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

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

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

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

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

最佳答案

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

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

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

关于c# - 为什么使用 EF/Linq to sql 创建性能不佳的查询如此容易，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18504392/