基于.NET Core 3与MongoDB 2.11驱动的仓储查询逻辑与性能疑问

针对你提出的两个疑问，结论非常明确：

• 构造函数中执行的GetCollection<T>()操作不会向MongoDB服务端发起任何数据读取请求，不会加载任何集合数据到本地内存。
• 所有基于传入的Expression<Func<T, bool>>的查询操作，MongoDB 2.11版本的.NET驱动会和Entity Framework的ORM逻辑一致，将表达式树翻译为原生的MongoDB查询指令下推到服务端执行，仅将匹配筛选条件的结果通过网络回传客户端，不会加载集合全量数据到本地做内存筛选。

关键细节说明 #

GetCollection<T>()的本质 #

该方法是纯内存操作，作用是生成目标集合的强类型引用代理：

• 初始化阶段仅加载该泛型类型对应的序列化映射规则，不会主动读取集合的元数据、不会校验集合是否存在，无任何网络IO开销
• 生成的IMongoCollection<T>实例占用内存极低，和集合本身存储的数据量没有任何关联，无论集合存储100条还是1亿条文档，该代理对象的大小完全一致。

查询执行的下推逻辑 #

驱动的表达式解析器会对传入的Lambda树做逐节点遍历，这一流程和EF Core将LINQ表达式翻译为SQL下推到关系型库执行的逻辑完全一致：

• 支持翻译的表达式会被转换为符合MongoDB协议的BSON过滤文档，随请求发送到服务端
• 服务端执行查询时会自动匹配已定义的索引优化查询性能，仅将符合过滤条件的文档序列化后返回
• 客户端收到响应后，才会将返回的BSON数据反序列化为自定义的T类型实体，整个过程的网络传输量仅和最终返回的结果集大小相关。

易踩的边界场景 #

仅当出现以下情况时，才会出现内存侧筛选、全量加载的问题，和你当前的仓储写法无关：

• 传入的Lambda表达式中使用了驱动不支持的C#自定义方法、无法翻译的内存计算逻辑
• 主动跳过驱动的查询封装，直接拉取全量游标后在客户端做遍历筛选
• 执行无任何过滤条件的全集合遍历操作

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