“IEnumerable”和“IQueryable”之间的主要区别在于在哪里执行筛选逻辑。一个在客户端(内存中)执行，另一个在数据库中执行。

例如，我们可以考虑一个例子，我们的数据库中有一个用户的10,000条记录，假设只有900个是活动用户，所以在这种情况下，如果我们使用“IEnumerable”，那么首先它将所有10,000条记录加载到内存中，然后应用IsActive筛选器，最终返回900个活动用户。

而另一方面，在同样的情况下，如果我们使用“IQueryable”，它将直接应用数据库上的IsActive过滤器，直接从那里将返回900个活跃用户。

是的，两者都使用延迟执行。让我们使用SQL Server分析器....来说明两者的区别

当我们运行以下代码时:

MarketDevEntities db = new MarketDevEntities();

IEnumerable<WebLog> first = db.WebLogs;
var second = first.Where(c => c.DurationSeconds > 10);
var third = second.Where(c => c.WebLogID > 100);
var result = third.Where(c => c.EmailAddress.Length > 11);

Console.Write(result.First().UserName);

在SQL Server分析器中，我们发现一个命令等于:

"SELECT * FROM [dbo].[WebLog]"

在有100万条记录的WebLog表上运行这段代码大约需要90秒。

因此，所有的表记录都作为对象加载到内存中，然后每个. where()都将是内存中针对这些对象的另一个过滤器。

当我们在上面的例子(第二行)中使用IQueryable而不是IEnumerable时:

在SQL Server分析器中，我们发现一个命令等于:

"SELECT TOP 1 * FROM [dbo].[WebLog] WHERE [DurationSeconds] > 10 AND [WebLogID] > 100 AND LEN([EmailAddress]) > 11"

使用IQueryable运行这段代码大约需要4秒钟。

IQueryable有一个名为Expression的属性，它存储了一个树表达式，当我们在示例中使用结果时开始创建这个树表达式(称为延迟执行)，在结束时，这个表达式将被转换为一个SQL查询，在数据库引擎上运行。

有一篇博客文章有简短的源代码示例，介绍了滥用IEnumerable<T>如何极大地影响LINQ查询性能:实体框架:IQueryable vs. IEnumerable。

如果我们深入挖掘并查看源代码，我们可以看到对于IEnumerable<T>有明显不同的扩展方法:

// Type: System.Linq.Enumerable
// Assembly: System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// Assembly location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Core.dll
public static class Enumerable
{
    public static IEnumerable<TSource> Where<TSource>(
        this IEnumerable<TSource> source, 
        Func<TSource, bool> predicate)
    {
        return (IEnumerable<TSource>) 
            new Enumerable.WhereEnumerableIterator<TSource>(source, predicate);
    }
}

和这个IQueryable < T >:

// Type: System.Linq.Queryable
// Assembly: System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// Assembly location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Core.dll
public static class Queryable
{
    public static IQueryable<TSource> Where<TSource>(
        this IQueryable<TSource> source, 
        Expression<Func<TSource, bool>> predicate)
    {
        return source.Provider.CreateQuery<TSource>(
            Expression.Call(
                null, 
                ((MethodInfo) MethodBase.GetCurrentMethod()).MakeGenericMethod(
                    new Type[] { typeof(TSource) }), 
                    new Expression[] 
                        { source.Expression, Expression.Quote(predicate) }));
    }
}

第一个返回可枚举的迭代器，第二个通过IQueryable source中指定的查询提供程序创建查询。

我们可以用同样的方法来使用它们，它们只是在性能上有所不同。

IQueryable仅以有效的方式对数据库执行。这意味着它创建了一个完整的选择查询，并且只获取相关的记录。

例如，我们想以名字以“Nimal”开头的前10名客户为例。在这种情况下，将生成select查询，从客户中选择名称为“Nimal%”的前10 *。

但是如果我们使用IEnumerable，查询就像select * from Customer，其中名称像' Nimal% '，前十位将在c#编码级别过滤(它从数据库中获取所有客户记录并将它们传递给c#)。

一般来说，您希望保留查询的原始静态类型，直到有必要。

出于这个原因，你可以将你的变量定义为'var'，而不是IQueryable<>或IEnumerable<>，你会知道你没有改变类型。

如果您开始使用IQueryable<>，通常希望将其保留为IQueryable<>，直到有一些令人信服的理由更改它。这样做的原因是您希望为查询处理器提供尽可能多的信息。例如，如果你只打算使用10个结果(你已经调用Take(10))，那么你想让SQL Server知道这一点，这样它就可以优化它的查询计划，只向你发送你将使用的数据。

A compelling reason to change the type from IQueryable<> to IEnumerable<> might be that you are calling some extension function that the implementation of IQueryable<> in your particular object either cannot handle or handles inefficiently. In that case, you might wish to convert the type to IEnumerable<> (by assigning to a variable of type IEnumerable<> or by using the AsEnumerable extension method for example) so that the extension functions you call end up being the ones in the Enumerable class instead of the Queryable class.

都能让你延期执行，没错。

至于哪个是首选的，这取决于您的底层数据源是什么。

返回一个IEnumerable将自动强制运行时使用LINQ to Objects来查询您的集合。

返回一个IQueryable(顺便说一下，它实现了IEnumerable)提供了额外的功能，可以将您的查询转换为可能在底层源上执行得更好的查询(LINQ to SQL, LINQ to XML，等等)。