EF Core 3.1+PostgreSQL：DBCommand执行快但总耗时超10倍问题排查

我正在使用EF Core 3.1 + PostgreSQL，执行以下查询代码：

var stopWatch = Stopwatch.StartNew();

var entity1 = await _context.Entity1
    .Include(e => e.Entity2)
    .Include(e => e.Entity3)
        .ThenInclude(e => e.Entity4)
    .FirstOrDefaultAsync(e => e.Id == someId);

stopWatch.Stop();
_logger.LogInformation($"Elapsed: {stopWatch.ElapsedMilliseconds} milliseconds.");

得到的日志如下：

[16:49:36 INF] Executed DbCommand (43ms) [Parameters=[@__Id_0='?' (DbType = Guid)], CommandType='Text', CommandTimeout='30']
SELECT t."Id", ....
...
ORDER BY ....
[16:49:36 INF] Elapsed: 400 milliseconds.

可以看到DBCommand执行仅耗时43ms，直接执行日志中的SELECT语句耗时相近，该查询返回45列、2000行数据集，但总耗时却达到400ms，接近DBCommand耗时的10倍。

我的问题：

1. 额外耗时来自哪里？是EF创建C#对象的时间吗？
2. 是否可以减少这部分耗时？

我已尝试使用AsNoTracking()，但似乎没有效果。

1. 额外耗时的来源 #

是的，大部分额外耗时确实来自EF Core的结果映射环节，具体包括：

• 实体映射与关联处理：EF需要把PostgreSQL返回的2000行、45列数据，逐个映射到Entity1及其关联的Entity2、Entity3、Entity4对象中，还要处理导航属性的关联关系（比如避免重复实例化关联实体），这部分逻辑本身就有不小的开销。
• 基础映射逻辑（即使AsNoTracking）：AsNoTracking()只是关闭了实体的变更跟踪，但EF Core 3.1仍会执行字段到属性的映射、关联实体的匹配等基础操作，这部分无法通过关闭跟踪完全消除。
• 数据类型转换：数据库返回的原始类型（比如PostgreSQL的uuid、timestamp）需要转换为对应的C#类型（Guid、DateTime），大量行的转换累积起来也会占用时间。

2. 减少耗时的方案 #

针对你的场景，可以尝试以下优化：

• 用投影查询替代完整实体加载：只查询实际需要的字段，避免加载45列中无用的数据，同时直接返回DTO或匿名类型，减少EF处理复杂实体关联的开销：

  var result = await _context.Entity1
      .Where(e => e.Id == someId)
      .Select(e => new 
      {
          e.Id,
          Entity2Info = new { e.Entity2.Name, e.Entity2.Code },
          Entity3List = e.Entity3.Select(eg => new 
          {
              eg.Id,
              Entity4Info = new { eg.Entity4.Value }
          })
      })
      .FirstOrDefaultAsync();
  

• 升级EF Core版本：EF Core 3.1是较旧的版本，后续5.0+版本对查询映射性能做了大量优化，尤其是关联查询的处理效率提升明显，项目允许的话升级能直接获得性能改善。
• 原生SQL+手动映射：如果投影查询仍不够，可以用FromSqlRaw执行原生SQL，再用AutoMapper的ProjectTo或手动代码完成结果映射，跳过EF部分内置的映射逻辑。
• 分批加载数据：如果业务允许，用Skip+Take分批获取2000行数据，减少单次映射的对象数量，分散耗时。

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