EF Core是否通过值比较生成Update列？大字段性能疑问

你的猜测完全正确！EF Core确实会通过对比属性的原始值和当前值，来决定哪些列需要包含在UPDATE语句中。

为什么你的代码里Confidence列没出现在UPDATE里？ #

EF Core的变更追踪机制会在你从数据库加载实体时，为每个属性记录一份原始值快照。当你修改实体属性后，调用SaveChangesAsync()时，EF Core会逐一对比每个属性的当前值和原始快照：

• 对于ModifiedDateTime，你赋值了新的UTC时间，和原始值不同，所以会被纳入UPDATE；
• 而Confidence你只是把原来的值重新赋值回去，EF Core检测到值没有变化，就不会把这个列加入UPDATE语句，这和你看到的SQL输出完全一致。

关于nvarchar(max)大文本列的性能担忧 #

你提到的4个nvarchar(max)列确实会带来潜在的性能问题——EF Core在对比这些大字符串时，会进行完整的内容比对，当字符串非常长时，这个操作的开销会很明显，尤其是在批量更新或者频繁更新主表但很少修改这些大列的场景下。

针对这个问题，你考虑拆分到附属表的方案是非常合理的，这里再补充几个思路：

• 拆分一对一附属表：把4个大文本列移到单独的WorkOrderDetails表，和WorkOrders表通过WorkOrderID建立一对一关联。这样平时更新WorkOrders主表时，EF Core只会追踪主表的属性，完全不会涉及到附属表的大文本列，从根源上避免了不必要的大值对比。
• 手动标记属性为未修改：如果暂时不想拆分表，可以在更新主表时，手动告诉EF Core不需要追踪这些大列的变化：

  var wo = await dbContext.WorkOrders.Where(x => x.WorkOrderID == 88).SingleOrDefaultAsync();
  wo.ModifiedDateTime = DateTime.UtcNow;
  // 标记大文本列未修改，跳过对比
  dbContext.Entry(wo).Property(x => x.LargeText1).IsModified = false;
  dbContext.Entry(wo).Property(x => x.LargeText2).IsModified = false;
  // 其他大列同理
  await dbContext.SaveChangesAsync();
  

  不过这个方法需要每次更新都手动处理，适合临时场景或者更新逻辑比较固定的情况。
• 使用无跟踪查询（谨慎使用）：如果你的场景只是读取后更新特定列，也可以考虑使用无跟踪查询（AsNoTracking()），然后手动构建UPDATE语句，但这样会失去EF Core变更追踪的便利性，适合性能要求极高的场景。

总的来说，拆分附属表是最彻底、最易维护的解决方案，能长期避免大值对比带来的性能损耗。

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