EF Core中获取Subcategory实体及关联产品数量的两种方法性能对比咨询

嘿，咱们来好好对比下这两种EF Core的查询方案，看看从性能角度谁更胜一筹——毕竟你既要拿到SubCategory实体，又要统计它下面的产品数量对吧？

方案一：两次独立轻量查询 #

先看代码：

var subcatgory = await _context.SubCategories.FirstOrDefaultAsync(m => m.Id == id);
int productCount = await _context.Products.CountAsync(p => p.SubCatgoryId == id);

这个方案会向数据库发送两条独立的SQL语句：

• 第一条只查询目标SubCategory的所有字段，非常轻量；
• 第二条是让数据库直接执行COUNT聚合，只返回一个数字。

性能优势： #

• 数据库只做最必要的事：要么拉取单条SubCategory数据，要么做聚合统计，两条SQL的执行效率都极高；
• 没有多余的数据传输：不会把产品的完整数据拉到应用服务器，只需要SubCategory实体和一个数字。

唯一的小缺点： #

多了一次数据库往返请求，但在绝大多数场景下，这个开销微乎其微——除非你的应用服务器和数据库跨了很远的网络（比如跨国部署），否则基本可以忽略。

方案二：Include关联后内存统计 #

再看第二种方案的代码：

var subcatgory = await _context.SubCategories.Include(s => s.Products).FirstOrDefaultAsync(m => m.Id == id);
int productCount = subcatgory.Products.Count();

这个方案会生成一条JOIN查询，数据库会把SubCategory和它关联的所有Product的完整数据都查出来，传输到应用服务器后，再在内存里统计数量。

性能问题： #

• 如果这个子分类下有大量产品，那这条查询会拉取巨量的冗余数据——你明明只需要产品的数量，却把每个产品的所有字段都加载进来了；
• 数据库要处理JOIN操作，应用服务器要占用更多内存存储这些Product对象，性能开销会随着产品数量的增加直线上升。

结论：方案一性能更优（绝大多数场景） #

除非你的子分类下只有个位数的产品，否则方案一的性能绝对碾压方案二。核心原因就是：

• 让数据库做它最擅长的聚合统计（COUNT），而不是把大量原始数据拉到内存里做计算；
• 两次轻量查询的总开销，远小于一次拉取大量关联数据的开销。

额外优化建议： #

如果你想进一步减少数据库往返，还可以用投影查询把两个需求合并成一次查询，这是更优的写法：

var result = await _context.SubCategories
    .Where(s => s.Id == id)
    .Select(s => new 
    {
        SubCategory = s,
        ProductCount = s.Products.Count()
    })
    .FirstOrDefaultAsync();

这种方式只会发送一条SQL，数据库内部完成关联和统计，返回你需要的SubCategory实体和产品数量，既省了一次往返，又不会加载多余数据，堪称完美。

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