ASP.NET Core Razor页AutoMapper映射超千行数据时速度慢如何优化

性能差和AutoMapper本身无关，是用法完全错误：

• 当前逻辑先执行SQL加载全量实体，包括Include关联表的所有字段，EF默认开启的变更跟踪还会为每个实体生成跟踪快照，产生第一重冗余开销
• 数据全部加载到内存后，逐行调用_mapper.Map<ViewModel>()做转换，每次映射都要重复执行规则匹配、对象初始化、属性赋值，上千行数据下内存分配和重复执行的开销会被线性放大，最终表现为转换极慢
• 整个流程完全没用到AutoMapper的IQueryable投影能力，所有转换压力全堆在应用内存侧。

1. 核心改造：用ProjectTo替代内存逐行映射 #

这是性能提升最明显的优化，普遍能带来10~100倍的速度提升。AutoMapper的Queryable扩展可以直接根据映射配置生成SQL SELECT语句，在数据库端完成字段投影，只返回ViewModel需要的字段，不需要加载全量实体到内存，也不需要在内存逐行做对象转换。
首先引入命名空间：

using AutoMapper.QueryableExtensions;

直接替换现有映射代码，在仓储返回的IQueryable上直接做投影：

// 使用ProjectTo时不需要在仓储层手动写Include，AutoMapper会自动根据映射的导航属性生成对应JOIN逻辑
var viewModelList = await _repository.GetAllAsync()
    .ProjectTo<ViewModel>(_mapper.ConfigurationProvider)
    .ToListAsync();

这种写法下EF生成的SQL只会拉取ViewModel用到的列，不会返回冗余字段，查询结果直接就是目标ViewModel集合，完全省去了内存转换的开销。

2. 排查映射配置的性能陷阱 #

• 不要在CreateMap的ForMember配置中写EF Core无法翻译的本地函数、复杂内存计算逻辑，这类逻辑会强制查询回退到客户端执行，拖慢整体速度
• 不需要映射循环引用的导航属性时，直接限制映射深度，避免AutoMapper递归遍历导航属性产生无效开销：

  cfg.CreateMap<ModelName, ViewModel>().MaxDepth(1);
  

• 如果你使用AutoMapper 11以下的旧版本，程序启动时调用_mapper.ConfigurationProvider.CompileMappings()预编译所有映射规则，避免运行时动态编译产生额外消耗，新版本默认启动时自动完成编译，不需要手动调用。

3. 场景优化 #

• 普通页面列表场景不要返回1000行以上全量数据，直接加分页逻辑，通过Skip()、Take()每次只查询10~50行，从根源降低数据处理量
• 如果确实需要加载全量实体（比如特殊业务逻辑处理后再映射），在仓储层查询时加上AsNoTracking()关闭变更跟踪，去掉跟踪快照的冗余开销：

  public IQueryable<ModelName> GetAllAsync()
  {
      return context.ModelName
                    .AsNoTracking()
                    .OrderByDescending(m => m.CreateOn)
                    .Include(m => m.Customer)
                    .Include(m => m.Town);
  }
  

  注意：使用ProjectTo时不需要加AsNoTracking，因为整个流程不会生成实体跟踪对象，没有这部分开销。

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