IEnumerable的谨慎使用和IQueryable 的延迟执行

 

 大家都知道可以使用IEnumerable<T> 的AddRange方法去获取指定范围的数据(常用于分页)。昨天我在做分页时当我取下来的数据时发现速度会很慢而且内存也消耗比较多,由此我们可以猜想到加载数据的时候肯定加载了很多不需要的数据。

代码:

Code

用SQL Server profiler 工具查看一下SQL 语句时果然IEnumerable<T>把所有的数据加载下来了再对其进行选择其中的数据,sql代码如下:

SELECT  
[ Extent1 ] . [ FID ]   AS   [ FID ]
[ Extent1 ] . [ BookName ]   AS   [ BookName ]
[ Extent1 ] . [ Author ]   AS   [ Author ]
FROM  (  SELECT   [ Extent1 ] . [ FID ]   AS   [ FID ] [ Extent1 ] . [ BookName ]   AS   [ BookName ] [ Extent1 ] . [ Author ]   AS   [ Author ] , row_number()  OVER  ( ORDER   BY   [ Extent1 ] . [ FID ]   ASC AS  
[ row_number ]
    
FROM   [ dbo ] . [ Book ]   AS   [ Extent1 ]
)  
AS   [ Extent1 ]
WHERE   [ Extent1 ] . [ row_number ]   >   0

ORDER BY [Extent1].[FID] ASC

由些可见IEnumerable生成的SQL语句是查询所有的数据,而不是生成查询指定记录的SQL语句。在上面PageList 的构造函数中 使用IEnumerable<T> source 参数,当我把IEnumerable<T> 把换成IQueryable<T>后再执行时发现速度明显提高了,再有SQL Server profiler 工具查看一下SQL代码:

SELECT   TOP  ( 10
[ Extent1 ] . [ FID ]   AS   [ FID ]
[ Extent1 ] . [ BookName ]   AS   [ BookName ]
[ Extent1 ] . [ Author ]   AS   [ Author ]
FROM  (  SELECT   [ Extent1 ] . [ FID ]   AS   [ FID ] [ Extent1 ] . [ BookName ]   AS   [ BookName ] [ Extent1 ] . [ Author ]   AS   [ Author ] , row_number()  OVER  ( ORDER   BY   [ Extent1 ] . [ FID ]   ASC AS  
[ row_number ]
    
FROM   [ dbo ] . [ Book ]   AS   [ Extent1 ]
)  
AS   [ Extent1 ]
WHERE   [ Extent1 ] . [ row_number ]   >   0
ORDER   BY   [ Extent1 ] . [ FID ]   ASC

 显然,这个才是我们真正需要的(因为我设置的是每页10条数据)--只查询我们指定数据。

思索结果:

  原来是IEnumerable<T> 泛型类在调用自己的SKip 和 Take 等扩展方法之前数据就已经加载在本地内存里了,而IQueryable<T> 是将Skip ,take 这些方法表达式翻译成T-SQL语句之后再向SQL服务器发送命令。也是延迟在我要真正显示数据的时候才执行。

以上只是我的个人想法,也不知道是否正确,不到之还望指点,欢迎大家拍砖。 如果有牛人路过实属万幸,希望能指点一二。

 

你可能感兴趣的:(query)