论EF+LINQ分页和数据库分页效率问题
RT
小弟一直纠结EF+LINQ是不是没有数据库分页的效率高  或者说EF+LINQ分页会占用更多资源
还有对于大数据呢  EF+LINQ是否还能胜任？期待你的解答 thx
------解决方案--------------------
项目里一个ORM都没用过。。。  只能帮顶了。。。
------解决方案--------------------
都答非所问！

EF分页也没什么问题，唯一的就是查询了所有字段，比如你有个content字段内容有1w字，这时候就有性能问题了。

所以查询的时候要select new 你查询的几个字段。但这样写法又不太简洁了。
------解决方案--------------------
使用skip()结合take()方法在LINQ里实现数据分页，效率上不比数据库分页差
------解决方案--------------------
你需要了解一下LINQ的延迟查询特性先

var q = from r in XXentities.XXX
             select r;

此时q里是没有数据的。
只有执行到 q.skip().take()时，才会去数据库取一页数据并返回
------解决方案--------------------

引用:

Quote: 引用:

都答非所问！

EF分页也没什么问题，唯一的就是查询了所有字段，比如你有个content字段内容有1w字，这时候就有性能问题了。

所以查询的时候要select new 你查询的几个字段。但这样写法又不太简洁了。

只存在查询所有字段的性能问题吗   没有其他的问题吗  例如数据库分页需要10条就查询10条  但是 EF会自动查询所有字段+所有数据  然后返回  是不是可以在linq语句中加top来过滤呢

不会取全部的，仅当用控件自带的分页才会那样
用Skip+Take。生成的SQL语句效率还是很高的，跟自己写的比较起来，稍微臃肿一点儿罢了


------解决方案--------------------
LINQ分页效率和直接用SQL完全等同，如果忽略接口开销的话。我不是说LINQ效率高，是这样的。

如果数据库支持RowNumber，那么LINQ会将Take Skip转化成where RowNumber > .. and < ... 这样的SQL执行，如果数据库不支持，LINQ会查出足够多的数据，然后再得到需要的。这也就是说，效率高不高和你用什么数据库（当然LINQ Provider也要支持）有关。