看看Entity Framework 4生成的复杂的分页SQL语句

本文通过对比EntityFramework4与LINQtoSQL生成的SQL语句,揭示两者在性能上的差异。发现EntityFramework4在某些场景下生成的SQL语句较为复杂,可能影响性能。

之前发现Entity Framework 4生成的COUNT查询语句问题,今天又发现它生成的分页SQL语句问题,而LINQ to SQL却不存在这个问题。

>>> 来看一看,瞧一瞧!

上代码:

2011012813363666.jpg

看生成的SQL语句:

1. Entity Framework生成的SQL:

2011012813432734.jpg

一个TOP,三个FROM。

2. LINQ to SQL生成的SQL:

2011012813471172.jpg

无TOP,两个FROM。

两者的差距一目了然。

>>> 再来看一个:

将上面代码中Where的查询条件改为常量,即Where(coder => coder.Age > 20),见下图:

2011012813560576.jpg

然后看看生成的SQL。

1. Entity Framework生成的SQL:

2011012813590326.jpg

明显不一样吧(颜色),实际上只是少了个exec sp_executesql,但会带来性能影响(sp_executesql will use cached plan to get more performance, 这里谈到了这个问题)。

2. LINQ to SQL生成的SQL与之前的一样。

 

Entity Framework考虑了多数据库支持、存储过程支持,却忽视了这个地方。

从LINQ to SQL的DataContext到Entity Framework的ObjectContext,然后又发布ADO.NET Entity Framework Feature CTP5搞了个DbContext,DbContext也没有解决这个问题,感觉微软的思路有些乱。

目前看来,如果用Entity Framework 4,并在乎性能,只有两个选择:1. 不用LINQ to Entities,自己写SQL或存储过程;2. 自己写个Entity Framework ADO.NET provider for SQL Server 。

更新:从执行计划来看, Entity Framework生成的SQL似乎对性能没什么影响。 

补充:

两个SQL的执行计划比较:

a) Entity Framework生成的SQL:

2011012817431089.jpg

b) LINQ to SQL生成的SQL:

2011012817435671.jpg

转载于:https://www.cnblogs.com/dudu/archive/2011/01/28/entity_framework_bad_sql.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值