Entity FrameWork 中使用Expression>访问数据库性能优化

时间:2022-09-17 18:49:28

问题的本质是:扩展的Where方法有四个参数重载。传进去Func<T,true>那么返回值是IEnumable的接口类型的集合,如果是Expression<Func<T,true>>那么返回的是IQueryable类型的接口集合。

而IQueryable接口类型的集合是支持延迟加载和自动根据条件生成sql的。

在使用Entity Framework 访问数据库时,我们经常使用Lambda表达式,但是如果不小心的话,很容易就掉到坑里了。比如下面的例子:用Lambda访问MSSqlServer中的NewsInfo表中id小于20的记录。

代码如下:

Entity FrameWork 中使用Expression<Func<T,true>>访问数据库性能优化

运行程序,程序工作正常。打开SQL Server Profiler 跟踪EF生成的SQL语句,结果如下:

Entity FrameWork 中使用Expression<Func<T,true>>访问数据库性能优化

这正是我们想要的SQL语句。下面我们将程序改一下,把Lambda表达式以参数的形式传递给一个方法GetNewsList(Func<NewsInfobool> lambda)。方法GetNewsList的代码如下:

Entity FrameWork 中使用Expression<Func<T,true>>访问数据库性能优化

 

Main()方法如下:

Entity FrameWork 中使用Expression<Func<T,true>>访问数据库性能优化

这时再次运行程序,程序工作正常,不过时间长了一些,用SQL Server Profiler跟踪,产生的SQL语句如下:

Entity FrameWork 中使用Expression<Func<T,true>>访问数据库性能优化

“坑”出现了,EF是直接从NewsInfo表中取出所有的数据到内存中,然后在内存中再做一次检索。显然,这样的方式在数据量小的时候并不太影响性能。但是在大数据量,高并发访问的时候,这种方式简直就是噩梦。

那么怎样改善呢?System.Linq.Expressions命名空间的Expression可以帮我们解决以上问题。修改后的GetNewsList()方法代码如下:

Entity FrameWork 中使用Expression<Func<T,true>>访问数据库性能优化

Main()方法不变。下面再次运行代码,并跟踪产生的SQL如下:

Entity FrameWork 中使用Expression<Func<T,true>>访问数据库性能优化

这下正常了。Expression<TDelegate>类可以以表达式目录树的形式将强类型 lambda 表达式表示为数据结构,从而在编译阶段产生我们想要的SQL代码。