看看Entity Framework 4生成的复杂的分页SQL语句
之前发现Entity Framework 4生成的COUNT查询语句问题,今天又发现它生成的分页SQL语句问题,而LINQ to SQL却不存在这个问题。
>>> 来看一看,瞧一瞧!
上代码:
看生成的SQL语句:
1. Entity Framework生成的SQL:
一个TOP,三个FROM。
2. LINQ to SQL生成的SQL:
无TOP,两个FROM。
两者的差距一目了然。
>>> 再来看一个:
将上面代码中Where的查询条件改为常量,即Where(coder => coder.Age > 20),见下图:
然后看看生成的SQL。
1. Entity Framework生成的SQL:
明显不一样吧(颜色),实际上只是少了个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:
b) LINQ to SQL生成的SQL:
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· spring官宣接入deepseek,真的太香了~
2009-01-28 发现自己
2008-01-28 博客园上海俱乐部第二次活动继续报道