实体框架的SQL查询性能

我试图让实体框架性能的句柄，特别是围绕动态SQL就会产生。以下面的语句为例：实体框架的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查询中尽可能高效？ EF的SQL代码

来源

2011-11-23 Fitzroy79

欢迎StackOverflow上：如果您发布的代码，XML或数据样本，** **请在高亮文本编辑器的线和编辑器工具栏上单击“代码示例”按钮（'{}'）很好地格式和语法突出显示它！ –

只是两点意见：首先，EF已经被广泛的测试，和它背后的人真正了解SQL Server和如何构建高效的查询，所以对于绝大多数的EF查询，会随着你会写什么好你自己 - 或更好。其次，EF使用参数化查询，所以如果相同的查询再次出现，只需使用不同的参数值，就可以重新使用缓存的执行计划 –

质量是应该担心你最少的事情。 EF本身足够慢。 SQL Server（尤其是最新版本）可以很好地进行查询优化，所以你通常不会比一些手写的SP慢。但总的来说，在使用EF的情况下，与使用ADO.NET + DataTables的纯请求相比，程序的响应速度会更慢，响应也更少。然而，这并不意味着EF是坏事，但你必须仔细考虑在哪里使用它。

来源

2011-11-23 12:31:57

实体框架的SQL查询性能

回答

相关问题