EF更新关联记录底层原理及主键重分配问题咨询

一、这种行为是否正常？ #

绝对不正常。正常情况下，Entity Framework执行更新操作时，应该生成UPDATE语句修改现有实体的字段，而不是删除旧实体再插入新实体（也就是不会改变主键值）。

出现这种情况，大概率是EF没有将你要更新的实体识别为「已存在的被跟踪实体」，反而把它当成了全新的实体来处理。常见的原因包括：

• 实体的主键属性没有正确配置：比如没加[Key]特性，或者Fluent API里没通过HasKey()指定主键，导致EF无法识别哪个字段是主键，进而错误判断实体状态
• 使用了分离实体（比如从前端接收DTO转换而来的实体，没有被当前DbContext实例跟踪），且没有手动将其附加到上下文并设置状态为Modified
• 关联实体的处理有误：比如在多对多/一对一关联场景中，导航属性没有正确赋值，导致EF误判实体的存在状态

你可以通过查看EF生成的SQL语句（比如开启日志）来确认：如果是DELETE+INSERT，那肯定是实体状态被标记为Added而非Modified了。

二、哪种主键最适合？ #

主键的选择取决于你的系统架构和业务场景，这里给你分情况说明：

1. 自增整数主键（Identity Column） #

• 适用场景：单体应用、数据量中等的业务系统
• 优点：占用空间小（4字节）、索引性能优异、EF默认支持，不需要手动生成主键值，数据库自动维护
• 缺点：分布式系统中如果有多数据库实例，容易出现主键冲突；数据跨库迁移时可能需要调整自增起始值

2. 顺序GUID/UUID主键 #

• 适用场景：分布式系统、微服务架构、需要在客户端生成主键的场景
• 优点：可以在客户端提前生成主键，避免分布式环境下的主键冲突；不需要依赖数据库自增逻辑
• 缺点：占用空间大（16字节），随机GUID会导致索引碎片，建议使用顺序GUID（比如EF Core中可以通过特定方式生成顺序值），索引性能略逊于整数主键

3. 业务主键（自然主键） #

• 适用场景：业务规则极其稳定，且有唯一业务标识的场景（比如用户身份证号、唯一业务编码）
• 优点：主键本身带有业务意义，不需要额外的主键字段
• 缺点：业务规则变更时（比如用户更换手机号）会导致主键修改，风险极高；性能通常不如自增/整数主键，容易出现重复或冲突问题

推荐方案 #

• 单体应用优先选自增整数主键，简单高效，维护成本最低
• 分布式/微服务系统优先选顺序GUID，避免分布式主键冲突
• 尽量避免使用业务主键，除非你能确保该业务标识永远不会改变

额外排查建议 #

如果你想解决当前的主键重分配问题，可以试试这些步骤：

• 检查实体类的主键配置：确保PartnersRegistry的RecordId字段标记了[Key]特性，或者在DbContext的OnModelCreating中通过modelBuilder.Entity<PartnersRegistry>().HasKey(p => p.RecordId)配置
• 调整更新逻辑：优先通过DbContext查询获取被跟踪的实体，修改属性后再保存，比如：

  var existingRecord = await unitOfWork.PartnersRegistry.FindAsync(recordId);
  if (existingRecord != null)
  {
      // 修改属性
      existingRecord.Name = updatedName;
      await unitOfWork.CompleteAsync();
  }
  

• 如果必须使用分离实体，记得手动附加并设置状态：

  unitOfWork.PartnersRegistry.Attach(updatedRecord);
  unitOfWork.Entry(updatedRecord).State = EntityState.Modified;
  await unitOfWork.CompleteAsync();
  

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