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

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

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

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

是的，两者都会让你延期执行。

区别在于IQueryable<T>是允许LINQ-to- sql (LINQ. sql)的接口。对任何事情)去工作。因此，如果在IQueryable<T>上进一步细化查询，该查询将在数据库中执行(如果可能的话)。

对于IEnumerable<T>情况，它将是LINQ-to-object，这意味着所有与原始查询匹配的对象都必须从数据库加载到内存中。

在代码:

IQueryable<Customer> custs = ...;
// Later on...
var goldCustomers = custs.Where(c => c.IsGold);

该代码将只对选择的黄金客户执行SQL。另一方面，下面的代码将在数据库中执行原始查询，然后在内存中过滤出非黄金客户:

IEnumerable<Customer> custs = ...;
// Later on...
var goldCustomers = custs.Where(c => c.IsGold);

这是一个非常重要的区别，在许多情况下，使用IQueryable<T>可以避免从数据库返回太多行。另一个主要的例子是分页:如果你在IQueryable上使用Take和Skip，你将只得到请求的行数;在IEnumerable< t>上这样做会导致你所有的行都被载入内存。

总的来说，我建议以下几点:

如果您想让开发人员使用您的方法在执行之前细化您返回的查询，则返回IQueryable<T>。 如果您想传输一组对象来枚举，则返回IEnumerable。

想象一下IQueryable是什么——一个数据的“查询”(如果你想，你可以对它进行细化)。IEnumerable是一组对象(已经接收到或创建了)，可以对其进行枚举。

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

出于这个原因，你可以将你的变量定义为'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 v. IQueryable问题。所使用的算法首先执行IQueryable查询以获得一组结果。然后将这些元素传递给foreach循环，并将这些元素实例化为实体框架(Entity Framework, EF)类。然后在Linq to Entity查询的from子句中使用这个EF类，导致结果为IEnumerable。

我对EF和实体的Linq相当陌生，所以花了一段时间才弄清楚瓶颈是什么。使用MiniProfiling，我找到了查询，然后将所有单独的操作转换为单个IQueryable Linq for Entities查询。IEnumerable执行了15秒，IQueryable执行了0.5秒。其中涉及三个表，在阅读本文后，我相信IEnumerable查询实际上形成了三个表的交叉积并过滤了结果。

尝试使用IQueryables作为经验法则，分析您的工作，使您的更改可测量。

有一篇博客文章有简短的源代码示例，介绍了滥用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中指定的查询提供程序创建查询。

之前已经说了很多，但回到根源，以一种更专业的方式:

IEnumerable是一个在内存中可以枚举的对象的集合——一个在内存中的序列，使得迭代成为可能(使得在每一个循环中都很容易，尽管你可以只使用IEnumerator)。它们就这样存在于记忆中。 IQueryable是一个表达式树，它将在某个时刻被转换成其他东西，并具有枚举最终结果的能力。我想这就是大多数人困惑的地方。

它们显然有着不同的内涵。

IQueryable表示一个表达式树(简单地说，就是一个查询)，一旦调用了发布api，它就会被底层查询提供者转换成其他东西，比如LINQ聚合函数(Sum, Count等)或ToList[数组，字典，…]。IQueryable对象也实现了IEnumerable, IEnumerable<T>，因此如果它们表示一个查询，那么该查询的结果可以被迭代。这意味着IQueryable不只是查询。正确的术语是它们是表达式树。

现在，这些表达式如何执行以及它们转向什么都取决于所谓的查询提供者(我们可以想到表达式执行器)。

在实体框架世界(即神秘的底层数据源提供程序或查询提供程序)中，IQueryable表达式被转换为本地T-SQL查询。Nhibernate对它们做了类似的事情。例如，您可以按照《LINQ:构建IQueryable Provider链接》中描述的概念编写自己的查询工具，并且您可能希望为您的产品存储提供者服务提供一个自定义查询API。

基本上，IQueryable对象一直在被构造直到我们显式地释放它们并告诉系统把它们重写成SQL或者其他什么然后发送到执行链进行后续处理。

就像延迟执行一样，它是一个LINQ特性，在内存中保留表达式树方案，并仅在需要时将其发送到执行中，无论何时针对序列调用某些api(相同的Count、ToList等)。

The proper usage of both heavily depends on the tasks you're facing for the specific case. For the well-known repository pattern I personally opt for returning IList, that is IEnumerable over Lists (indexers and the like). So it is my advice to use IQueryable only within repositories and IEnumerable anywhere else in the code. Not saying about the testability concerns that IQueryable breaks down and ruins the separation of concerns principle. If you return an expression from within repositories consumers may play with the persistence layer as they would wish.

A little addition to the mess :) (from a discussion in the comments)) None of them are objects in memory since they're not real types per se, they're markers of a type - if you want to go that deep. But it makes sense (and that's why even MSDN put it this way) to think of IEnumerables as in-memory collections whereas IQueryables as expression trees. The point is that the IQueryable interface inherits the IEnumerable interface so that if it represents a query, the results of that query can be enumerated. Enumeration causes the expression tree associated with an IQueryable object to be executed. So, in fact, you can't really call any IEnumerable member without having the object in the memory. It will get in there if you do, anyways, if it's not empty. IQueryables are just queries, not the data.

是的，两者都使用延迟执行。让我们使用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)。

IQueryable扩展了IEnumerable接口。(你可以发送一个IQueryable给一个期望IEnumerable而没有错误的对象。)

(2) IQueryable和IEnumerable LINQ在迭代结果集时都尝试延迟加载。(注意，可以在每种类型的接口扩展方法中看到实现。)

换句话说，IEnumerables不是独占的“内存中”。IQueryables并不总是在数据库上执行。IEnumerable必须将数据加载到内存中(一旦检索到，可能是惰性的)，因为它没有抽象数据提供程序。IQueryables依赖于抽象提供者(如LINQ-to-SQL)，尽管这也可以是. net内存中的提供者。

样例用例

(a)从EF上下文检索IQueryable记录列表。(内存中没有记录。)

(b)将IQueryable传递给模型为IEnumerable的视图。(有效。IQueryable扩展IEnumerable。)

(c)在视图中遍历并访问数据集的记录、子实体和属性。(可能会导致异常!)

可能的问题

IEnumerable尝试延迟加载，你的数据上下文过期了。由于提供程序不再可用而引发异常。

(2)实体框架实体代理已启用(默认)，并且您尝试访问具有过期数据上下文的相关(虚拟)对象。同(1)。

(3)多活动结果集(MARS)。如果你在foreach(var record in resultSet)块中遍历IEnumerable，同时尝试访问record. childentity。childProperty，由于数据集和关系实体的惰性加载，您可能最终会得到MARS。如果在连接字符串中未启用该选项，则会导致异常。

解决方案

我发现在连接字符串中启用MARS工作不可靠。我建议你避免MARS，除非它被很好地理解和明确地渴望。

执行查询并通过调用resultList = resultSet.ToList()来存储结果，这似乎是确保实体位于内存中的最直接的方法。

在访问相关实体的情况下，可能仍然需要数据上下文。或者，您可以禁用实体代理，并显式地从DbSet中包含相关实体。

上面的答案很好，但它没有提到解释两个接口“如何”不同的表达式树。基本上，有两组相同的LINQ扩展。Where()， Sum()， Count()， FirstOrDefault()等都有两个版本:一个接受函数，一个接受表达式。

IEnumerable版本签名为:Where(Func<Customer, bool> predicate) IQueryable版本签名是:Where(表达式<Func<Customer, bool>>谓词)

你可能在没有意识到的情况下使用了这两个函数，因为它们使用相同的语法调用:

例如，Where(x => x.City == "<City>")对IEnumerable和IQueryable都有效

当在IEnumerable集合上使用Where()时，编译器将一个编译后的函数传递给Where() 当在IQueryable集合上使用Where()时，编译器将表达式树传递给Where()。表达式树类似于反射系统，但用于代码。编译器将代码转换为数据结构，该结构以易于理解的格式描述代码的功能。

为什么要用这个表达式树呢?我只想让Where()过滤我的数据。 主要原因是EF和Linq2SQL orm都可以将表达式树直接转换为SQL，这样您的代码将执行得更快。

哦，这听起来像一个免费的性能提升，我应该在这种情况下使用AsQueryable()吗? 不，IQueryable只有在底层数据提供程序可以使用它时才有用。将常规列表转换为IQueryable不会给你带来任何好处。

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

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

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

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

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

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

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

除了前两个非常好的答案(由driis和Jacob):

IEnumerable 接口在系统中。集合名称空间。

IEnumerable对象表示内存中的一组数据，并且只能根据这些数据向前移动。由IEnumerable对象表示的查询立即完整地执行，因此应用程序可以快速地接收到数据。

当执行查询时，IEnumerable加载所有数据，如果我们需要对其进行筛选，筛选本身是在客户端完成的。

可查询接口位于系统中。Linq命名空间。

IQueryable对象提供了对数据库的远程访问，并允许您以从头到尾的直接顺序或反向顺序在数据中导航。在创建查询的过程中，返回的对象是IQueryable，查询是优化的。因此，在执行过程中消耗的内存更少，网络带宽更少，但同时它的处理速度比返回IEnumerable对象的查询稍微慢一些。

选择什么?

如果您需要返回的整个数据集，那么最好使用IEnumerable，它提供了最大的速度。

如果你不需要整个返回的数据集，而只是一些过滤后的数据，那么最好使用IQueryable。

除了上面的，有趣的是，如果你使用IQueryable而不是IEnumerable，你可以得到异常:

如果products是一个IEnumerable，下面的工作很好:

products.Skip(-4);

然而，如果products是一个IQueryable对象，并且它试图从DB表中访问记录，那么你会得到这个错误:

offset子句中指定的偏移量不能为负。

这是因为构造了以下查询:

SELECT [p].[ProductId]
FROM [Products] AS [p]
ORDER BY (SELECT 1)
OFFSET @__p_0 ROWS

OFFSET不能为负值。