EF Core中检查导航属性是否存在关联数据的最高效方法

你当前代码的性能问题完全来自于多余的Include调用，针对需求有两种成熟的优化方案：

方案1：移除Include直接投影（最推荐） #

当使用Select做自定义DTO投影时，EF Core 会自动解析表达式中用到的导航属性，不需要手动调用Include预加载关联数据。你写的x.Metrics.Any()会被EF Core直接翻译成SQL层的EXISTS子查询，不会加载任何AssetMetric实体数据，性能远高于你现在的实现：

var summary =  await _dbContext.Assets
    .Select(x => new AssetSummary()
    {
        Name = x.Name,
        HasMetrics = x.Metrics.Any(),
    }).ToListAsync();

这个方案的优势是代码简洁、可读性高，EF Core 生成的SQL执行效率已经接近原生手写SQL，适合绝大多数业务场景。

方案2：手动GroupJoin关联查询（适合极端性能场景） #

如果你需要完全控制关联逻辑，避免EF Core自动生成SQL的不可控性，可以手动写分组关联查询，执行效率和方案1基本一致：

var summary = await _dbContext.Assets
    .GroupJoin(
        _dbContext.AssetMetrics,
        asset => asset.Id,
        metric => metric.AssetId,
        (asset, metrics) => new AssetSummary
        {
            Name = asset.Name,
            HasMetrics = metrics.Any()
        }
    ).ToListAsync();

原代码性能差的原因 #

你添加的Include(x => x.Metrics)会强制EF Core预加载所有Asset关联的全量AssetMetric数据到内存，Any判断是在内存中执行的，当子表数据量大的时候会产生非常高的IO和内存开销，移除Include后所有判断逻辑都在数据库端执行，只返回你需要的Name和HasMetrics两个字段，数据传输量和执行效率都会有数量级的提升。

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