Entity FrameWork 中使用Lambda访问数据库性能优化
在使用Entity Framework 访问数据库时，我们经常使用Lambda表达式，但是如果不小心的话，很容易就掉到坑里了。比如下面的例子：用Lambda访问MSSqlServer中的NewsInfo表中id小于20的记录。
代码如下：
运行程序，程序工作正常。打开SQL Server Profiler 跟踪EF生成的SQL语句，结果如下：
这正是我们想要的SQL语句。下面我们将程序改一下，把Lambda表达式以参数的形式传递给一个方法GetNewsList(Func<NewsInfo, bool> lambda)。方法GetNewsList的代码如下：
Main()方法如下：
这时再次运行程序，程序工作正常，不过时间长了一些，用SQL Server Profiler跟踪，产生的SQL语句如下：
“坑”出现了，EF是直接从NewsInfo表中取出所有的数据到内存中，然后在内存中再做一次检索。显然，这样的方式在数据量小的时候并不太影响性能。但是在大数据量，高并发访问的时候，这种方式简直就是噩梦。
那么怎样改善呢？System.Linq.Expressions命名空间的Expression可以帮我们解决以上问题。修改后的GetNewsList()方法代码如下：
Main()方法不变。下面再次运行代码，并跟踪产生的SQL如下：
这下正常了。Expression<TDelegate>类可以以表达式目录树的形式将强类型 lambda 表达式表示为数据结构，从而在编译阶段产生我们想要的SQL代码。
问题的本质是：扩展的Where方法有四个参数重载。传进去Func<T,true>那么返回值是IEnumable的接口类型的集合，如果是Expression<Func<T,true>>那么返回的是IQueryable类型的接口集合。
而IQueryable接口类型的集合是支持延迟加载和自动根据条件生成sql的。
IQueryable才是问题的关键，它也成就了Linq to anything
ps：抓住问题的本质。