EF Core 2.0/2.1如何高效处理大且少访问的列？

当然可以实现LargeBlob的延迟加载，而且针对你这种99%场景只需要基础字段的情况，还有几个更高效的方案，我来给你逐一说明：

1. 延迟加载（依赖ORM框架，比如Entity Framework） #

你的实体类里已经把LargeBlob标记为virtual了，这在EF（包括EF Core）里是开启延迟加载的前提之一。不过需要确保你的ORM配置正确：

• 对于EF Core，需要安装Microsoft.EntityFrameworkCore.Proxies包，然后在上下文配置中启用代理和延迟加载：

  protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
  {
      optionsBuilder.UseSqlServer("你的连接字符串")
                    .UseLazyLoadingProxies(); // 启用延迟加载代理
  }
  

• 这样一来，当你查询Entity时，LargeBlob会在你第一次访问它的时候才从数据库加载。

⚠️ 注意事项：

• 延迟加载依赖于DbContext的生命周期，如果你在上下文已经释放后再访问LargeBlob，会抛出异常。
• 要避免“N+1查询”问题，如果批量处理实体，延迟加载可能会导致多次数据库请求。

2. 显式加载（更可控的方式） #

因为只有1%的场景需要LargeBlob，显式加载其实是更稳妥的选择——完全由你控制加载时机，不会意外触发不必要的查询。

当你需要加载某个实体的LargeBlob时，手动调用加载方法：

// 先获取基础实体
var entity = _context.MyTable.FirstOrDefault(e => e.Id == 1);
// 当需要Blob时，显式加载
if (entity != null)
{
    _context.Entry(entity).Reference(e => e.LargeBlob).Load();
}

如果是批量加载，可以用Include的变体，但只在需要的时候用：

// 仅在需要Blob的场景中，才Include这个字段
var entitiesWithBlob = _context.MyTable.Include(e => e.LargeBlob).ToList();

3. 投影查询（最直接的性能优化） #

在99%的业务场景里，你其实根本不需要查询LargeBlob字段——直接用投影查询返回仅包含Id和Name的结果即可，不管是匿名类型还是专门的DTO：

// 匿名类型示例
var basicData = _context.MyTable.Select(e => new { e.Id, e.Name }).ToList();

// 或者定义DTO类
public class EntityBasicDto
{
    public int Id { get; set; }
    public string Name { get; set; }
}
var basicDtos = _context.MyTable.Select(e => new EntityBasicDto { Id = e.Id, Name = e.Name }).ToList();

这种方式的优点是从SQL层面就排除了LargeBlob字段，完全避免了不必要的数据传输，性能最优，也是我最推荐的方案。

4. 表拆分/实体拆分 #

如果LargeBlob的数据量特别大，你可以考虑把它拆分到单独的表中，和原表建立一对一关联：

• 数据库层面：新建MyTableBlob表，包含Id（和原表主键一致）和LargeBlob字段，设置外键关联MyTable.Id。
• 实体层面：可以拆分为两个实体，或者在EF中配置表拆分，让Entity类的LargeBlob映射到单独的表。

这样默认查询MyTable时不会关联Blob表，需要的时候再通过关联查询获取，从物理存储层面分离了大字段，也能有效减少常规查询的数据量。

总结一下，优先推荐投影查询，因为它最直接高效；如果需要操作完整实体，显式加载比延迟加载更可控；延迟加载适合需要实体完整性但大部分场景不用Blob的情况；表拆分则适合Blob数据极大、需要物理隔离的场景。

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