DbContext添加数据后返回错误ID问题排查咨询

看起来你碰到了个只在生产环境出现的棘手问题——EF返回的Pin Id和数据库实际生成的对不上，本地和预发布都正常。我给你梳理几个优先级较高的排查方向：

1. 先确认数据库的自增序列状态 #

首先得搞清楚生产环境里Pins表的主键列（pin）的自增配置：

• 如果用的是SQL Server，执行这条查询：

  SELECT IDENT_CURRENT('Pins') AS CurrentIdentity, IDENT_SEED('Pins') AS Seed, IDENT_INCR('Pins') AS Increment
  

  看看当前的自增序列值是不是1310（和数据库里最新的ID匹配）。要是序列值是1300但数据库里已经有1300的记录，说明要么有人开了IDENTITY_INSERT手动插过数据，要么有事务回滚导致序列跳号了。这种情况下次插入数据库会尝试用1300，但因为已存在应该会报错，不过你说SaveChanges成功了，那大概率是EF没依赖数据库自增，而是自己生成Id了。

2. 检查EF的主键生成策略配置 #

你的Pin模型里Id只加了[Key]和[Column]，没明确标[DatabaseGenerated(DatabaseGeneratedOption.Identity)]。虽然EF6对int主键默认是自增策略，但生产环境可能有配置被覆盖：

• 看看MyDbContext的OnModelCreating方法里，有没有类似这样的代码：

  modelBuilder.Entity<Pin>().Property(p => p.Id).HasDatabaseGeneratedOption(DatabaseGeneratedOption.None);
  

  如果有，EF会在客户端生成Id，不用数据库自增。这种情况下多实例部署很容易撞Id，导致你看到的现象：EF生成1300，插入时发现已被占用，数据库自动用了下一个可用的1310，而EF还拿着自己生成的1300。

3. 排查数据库触发器或自定义逻辑 #

生产环境的Pins表有没有插数据的触发器？比如有些触发器会强制替换主键值（比如用另一个序列）：

• 查看表的触发器定义，确认插入操作是不是被触发器改了pin列的值。要是触发器把EF传的1300换成了数据库自增的1310，EF就不知道这个变化，返回的还是原来的1300。

4. 验证多实例部署的Id冲突 #

如果生产环境是多个应用实例在跑，而且EF用的是客户端生成Id的策略：

• 不同实例可能生成重复的Id，比如实例A生成1300准备插入，但这个Id已经被实例B之前插的记录占了。要是数据库开了IDENTITY_INSERT ON，可能会自动跳过冲突Id用1310，而EF还以为插的是1300。

5. 检查数据库驱动和EF版本兼容性 #

生产环境的数据库驱动（比如SQL Server的SqlClient）版本和本地/预发布是不是一致？

• 有些旧版本驱动在处理自增主键返回值时可能有bug，导致EF拿到错误的Id。

6. 排查事务隔离级别（概率较低） #

虽然可能性不大，但可以看看生产环境的数据库事务隔离级别：

• 如果是READ UNCOMMITTED，会不会出现EF读取到未提交的旧Id？不过SaveChanges是同步操作，正常应该等数据库返回正确的生成Id才对。

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