zoukankan      html  css  js  c++  java
  • 看看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:

  • 相关阅读:
    「SAM」你的名字
    「疫期颓废」2
    「疫期颓废」1
    代码覆盖率简单介绍
    解决git报ssh variant 'simple' does not support setting port
    接口自动化基本流程和测试思路
    wait和sleep的区别
    vm垃圾回收算法的简单理解
    TCP-三次握手和四次挥手简单理解
    浏览器输入一个url 中间经历的过程
  • 原文地址:https://www.cnblogs.com/dudu/p/entity_framework_bad_sql.html
Copyright © 2011-2022 走看看