EF6更新已有主表记录时关联子表新数据未入库问题咨询

AddOrUpdate()是EF6提供的单实体upsert扩展，本身不支持级联遍历导航属性自动处理子实体状态，这是你遇到问题的核心原因。
两种场景下行为不一致的逻辑非常明确：

• 传入的Device是全新未入库记录时，EF将主实体标记为Added状态，默认的级联规则会把同上下文中未追踪的关联Datalogs也一并标记为Added，调用SaveChanges时会连带插入子表数据。
• 传入的Device是已存在记录时，AddOrUpdate会将主实体标记为Modified/Unchanged状态，此时EF不会主动遍历导航属性中的子实体，你传入的Datalogs对象没有被上下文追踪、也没有被显式标记状态，EF不会为其生成SQL语句，自然不会写入数据库。
  你之前逐行调用context.Datalogs.AddOrUpdate(log)性能差的原因也很直接：每次调用AddOrUpdate都会单独发起一次数据库查询判断记录是否存在，批量写入场景下查询开销会被线性放大，数据量稍大就会有明显的性能问题。

不需要为每条关联记录单独写更新逻辑，按时序采集数据的场景特性实现即可，性能远高于逐行AddOrUpdate：

1. 先确定子实体的业务唯一键 #

Datalogs是设备采集的时序数据，业务层面同一个设备同一个采集时间点不会产生重复记录，不要依赖自增主键Id做重复判断，用Device_Id + Recorded作为业务唯一键判定重复即可。

2. 显式分离主从实体处理逻辑，避免不必要的状态检查 #

不要依赖主实体的AddOrUpdate做级联处理，显式标记子实体状态，减少无效数据库查询：

public static bool Write_to_DB(Device device)
{
    using (var context = new Factory_Sensors())
    using (var transaction = context.Database.BeginTransaction())
    {
        // upsert主设备记录，按主键Id判定
        context.Devices.AddOrUpdate(d => d.Id, device);
        context.SaveChanges(); // 提前保存主实体，确保新设备的自增Id正确回填

        // 一次性查询当前设备已存在的采集记录时间戳，放到内存哈希表做重复判断
        var existingRecordTimes = new HashSet<DateTime>(
            context.Datalogs
                .Where(log => log.Device_Id == device.Id)
                .Select(log => log.Recorded)
        );

        foreach (var log in device.Datalogs)
        {
            // 已存在的记录直接跳过，采集数据写入后不会修改，不需要做更新操作
            if (existingRecordTimes.Contains(log.Recorded))
                continue;
            
            // 显式标记为新增状态，不会触发AddOrUpdate自带的存在性查询，开销极低
            log.Device_Id = device.Id;
            context.Datalogs.Add(log);
        }

        context.SaveChanges();
        transaction.Commit();
        return true;
    }
}

3. 大数据量场景的性能优化 #

如果单次写入的Datalogs条目超过100条，可以直接用基于SqlBulkCopy实现的EF6批量插入能力，跳过EF逐行生成SQL的流程，直接走SQL Server的批量导入接口，写入性能可以提升10~50倍，适合高频采集的工业场景。
注意：如果你的业务规则是采集数据写入后永远不会修改，完全不需要对子实体调用AddOrUpdate，只需要过滤掉已存在的时间戳记录，剩余新记录直接批量插入即可，这是时序数据场景下效率最高的实现方式。

EF6原生没有提供集合级别的AddOrUpdate实现，也不存在相关的配置开关可以让框架自动识别导航属性的子实体状态——因为级联upsert的逻辑完全依赖业务规则：有的场景子实体只新增不修改，有的场景需要同步更新子实体、还要删除本次提交中不存在的旧子项，框架无法给出通用的默认实现，所以这部分逻辑需要开发者按业务场景显式实现。

内容的提问来源于stack exchange，提问作者High Plains Grifter