Question

我正在尝试处理实体框架性能，特别是它将生成的动态SQL。例如，请使用以下语句：

var orders = db.Orders.Include(o => o.OrderItem).Include(o => o.Customer);

将为所有订单附加订单商品以及订购商品的客户详细信息返回。

这将粗略地转换为SQL，如下所示：

Select * 
from Order o 
inner join OrderItem oi on o.OrderId = oi.OrderId 
inner join Customer c on o.CustomerId = c.CustomerId

现在（在SQL Server的上下文中）这个计划可能会被缓存，这个例子非常简单，但随着查询变得越来越动态和复杂，带有参数，条件，变量等，数据库性能变得如此EF的问题，并将使用编译的存储过程或其他对象，而不是让EF生成动态SQL变得更有效？

或者我们可以假设EF是高度优化的，除了复杂场景中数据库级别需要SPROCS，视图，函数等的场景之外，我们可以依赖EF在其SQL查询中尽可能高效吗？

Answer 1

EF SQL代码的质量是最不值得担心的事情。 EF本身就足够慢。 SQL Server（尤其是最新版本）可以进行非常好的查询优化，因此通常它们不会比某些手写SP更慢。但总的来说，使用EF后，与使用纯粹的请求a-la ADO.NET + DataTables相比，程序会慢得多，反应也慢。然而，这并不意味着EF是坏事，但你必须仔细考虑在哪里使用它。

实体框架SQL查询性能

1 个答案: