为何普遍认为IEnumerable在内存过滤数据而IQueryable在服务端执行？

常见认知的偏差 #

不少关于IEnumerable和IQueryable的讨论都持有这样的观点：IEnumerable在内存中过滤数据，IQueryable在服务端执行过滤。但实际情况并非如此——IEnumerable仅在查询被拆分执行时，才会在内存中完成后续过滤。

链式调用的IEnumerable：服务端执行过滤 #

比如这样编写代码：

IEnumerable<Customer> customers = context.Customers.Where(c => c.FirstName.StartsWith("J")).Take(5).ToList();

生成的SQL会包含top(5)的过滤条件：

select top(5) * from Customers WHERE FirstName like 'j%';

可见Where和Take都被转换成SQL语句，在数据库服务端完成了过滤，和“内存过滤”的说法完全矛盾。

拆分查询的IEnumerable：内存中执行后续过滤 #

但如果把查询拆分成两步写：

IEnumerable<Customer> customers = context.Customers.Where(c => c.FirstName.StartsWith("J"));
var result = customers.Take(5).ToList(); // 过滤逻辑拆分到不同代码行

这时生成的SQL就没有top(5)：

select * from Customers WHERE FirstName like 'j%';

这说明Take(5)这一步是在内存中对已加载的数据进行过滤的。

认知误区的根源 #

核心问题在于大家混淆了变量的声明类型和实际执行的查询逻辑：

• EF Core的DbSet<T>本身实现了IQueryable接口，当你直接链式调用Where、Take等方法时，调用的是Queryable类的扩展方法——这类方法会把操作转换成表达式树，最终由EF Core翻译成SQL在服务端执行。哪怕你最后把结果赋值给IEnumerable变量，因为ToList()触发了查询执行，所有过滤逻辑已经在服务端完成了。
• 但如果先把IQueryable的中间结果赋值给IEnumerable变量，后续对这个变量调用Take时，调用的是Enumerable类的扩展方法——这类方法基于委托实现，只能对已经加载到内存中的集合进行操作，所以后续过滤自然就在内存中完成了。

简单说，决定过滤是在服务端还是内存执行的，不是变量声明的类型，而是你调用的是Queryable还是Enumerable的扩展方法。

内容的提问来源于stack exchange，提问作者Aleksander Chelpski