ADO.NET 实体框架是否因生成性能不佳的查询而闻名？

Question

这个问题的灵感来自发布到最新 ServerFault 博客文章的评论：

你们还在使用 LINQ to SQL 吗？

我知道我可以使用SQL Server Profiler和/或该ToTraceString方法来查看生成的查询和分析他们自己。但是，我正在寻找具有管理由使用实体框架的应用程序访问的数据库的实践经验的人的意见。

实体框架查询是性能问题的常见原因吗？
在这种情况下可以优化 LINQ 查询还是原始 Transact-SQL 是唯一的解决方案？

Answer 1

这取决于查询是什么。ORM 通常非常擅长 CRUD，因为它们通常很简单。查询越复杂，错误查询的可能性就越大。您可以通过调整 LINQ 语句来调整生成的查询。不过，您迟早会厌倦对任何复杂的事情进行斗争并使用 SQL 查询或存储过程。

Answer 2

个别查询没问题

\n\n

ORM 工具（Entity Framework、Linq、LLBLGen、NHibernate等）最大的性能“问题”之一并不是执行的各个查询的性能（大多数只是检索 CRUD 调用）基于主键的单个记录）。

\n\n

延迟加载的不正确使用 = 性能不佳

\n\n

这是延迟加载的错误使用，如果您没有正确设置预取属性，您最终可能会对数据库执行大量执行（本来可以在对数据库的单次调用中检索的内容会变成 200 个单独的执行，以及与之相关的所有网络和 IO 开销）

\n\n

从LINQ 到 SQL、延迟加载和预取

\n\n

\n

事实证明，每次访问 ProjectEntity 和 CustomerEntity 对象都会在第一次引用特定项目或实体时导致对服务器（如图所示）进行单独的查询。这意味着对于应用程序中的每个项目，都会有两个额外的查询访问服务器，因此如果我显示 20 个项目，我会额外访问数据库 40 次。 \x80\x99s 为您延迟加载，\xe2\x80\x99s\n 通常基于列表的问题显示如下。如果您显示的每一行都需要一个或多个相关实体，情况可能会更糟。

\n

\n\n

关键是知道您正在访问什么

\n\n

使用 ORM 和自己手动编写它之间的真正区别在于，当您自己编写代码时，您被迫思考 SQL 应该如何构建，并且您可以轻松地针对您要解决的特定场景进行调整。

\n\n

然而，当使用 ORM 时，您会受到 ORM 工具提供的选项和自定义的限制，并且许多开发人员只是将其留给 ORM 工具本身（假设/希望它会提出最佳计划），这就是 ORM 的原因工具被广泛认为适用于 CRUD，但不适用于更复杂的操作......

\n\n

注意：延迟加载可能是一件非常好的事情，但当它使用不当时，这就是问题所在......

\n