IQueryable 与 IEnumerable

Question

考虑以下片段：

IQueryable<Person> pQ = from p in db.People select p;
IEnumerable<Person> pE = pQ;

Console.WriteLine(pQ.Count());
Console.WriteLine(pE.Count());

两者都给出相同的结果，但如果您跟踪生成的 SQL，IQueryable 版本使用COUNT 发出查询，而IEnumerable 版本只发出SELECT，拉入所有行并执行在内存中计数，这可能是非常低效的。这同样适用于其他方法，例如 Sum() 和 Average()，并且在 EF6 和 EF Core 3 中都会出现。

原因是Count() 是一个扩展方法，因此绑定到变量的静态类型（第一种情况下为IQueryable，第二种情况下为IEnumerable）而不是动态类型（两者都相同）情况，因为它是同一个对象）。

这是一个非常讨厌的问题，这意味着在这种情况下通常最好避免使用IEnumerable。但是，有一个解决方法：

Console.WriteLine(pE.AsQueryable().Count());

这意味着SQL COUNT 已发出。

（注意：转换为IQueryable 也可以在这里工作，但不是一般情况下 - 如果IEnumerable 纯粹是指内存中的数据，那么转换会失败，但AsQueryable() 会简单地将对象包围在一个中性的包装器。）

我的问题是：既然这个问题很容易被忽视并且会导致这种低效的行为，为什么对AsQueryable() 的调用不简单地嵌入到扩展方法的IEnumerable 实现中？

Answer 1

我的问题是：既然这个问题很容易被忽视并且会导致这种低效的行为，为什么对AsQueryable() 的调用不简单地嵌入到扩展方法的IEnumerable 实现中？ em>

原因是您并不总是想调用IQueryable 扩展方法。

如果源的类型实现IQueryable<T>， AsQueryable<TElement>(IEnumerable<TElement>) 直接返回。 否则，它返回一个IQueryable<T>，它通过以下方式执行查询 在Enumerable 中调用等效的查询运算符方法，而不是 Queryable中的那些。

如果您想具体化查询，您可以调用返回IEnumerable<T> 的AsEnumerable 方法或使用对IEnumerable<T> 变量的赋值（如您所做的那样），然后调用Count 方法将再次调用AsQueryable方法将返回原始IQueryable<T> 对象并为IQueryable<T> 执行Count。

问题在于IQueryable 使用QueryProvider 将给定的表达式树转换为实际查询，并且并非每个表达式树都可以转换为可能导致错误的有效查询。有许多查询提供程序不够成熟/不够成熟，在这种情况下它只是抛出异常。我认为这甚至比性能下降还要糟糕。此外 Entity Framework Core 团队认为，由于某些查询被部分翻译，其余部分在本地评估（幸运的是 EFCore 不会引发异常）。

如果我可以建议您如何处理这个可能被忽视的问题，我会编写 roslyn 分析器，它会调查代码并查找 IEnumerable<T> enumerable = queryable; 分配并在发现问题时发出警告。 GitHub 上可能已经实现了一些，因为您可能不是唯一处理它的人。