使用EF Core原生SQL查询能否规避余额更新的并发问题？

原生SQL直接更新的可行性 #

用UPDATE Person SET Balance = Balance + @amount WHERE id = @personId这类原生SQL语句直接更新余额，完全可以避免应用层面的并发问题。

原因很简单：这个操作是数据库层面的原子操作——数据库会在单个事务内锁定目标行，一次性完成「读取当前Balance→计算新值→写入新值」的全部流程，整个过程不会被其他请求打断。对比先查询实体到内存、再计算更新的传统方式，后者在查询和更新之间存在时间窗口，其他请求可能在此期间修改数据库中的Balance，导致最终更新基于旧值覆盖了中间修改；而原生SQL把这两步合并为数据库端的原子操作，根本不存在中间状态暴露给其他请求的情况。

其他最佳方案 #

除了原生SQL，还有两种更贴合EF Core生态的方案可选：

1. EF Core ExecuteUpdate 方法（EF Core 7+） #

EF Core 7及以上版本提供了ExecuteUpdate方法，无需写原生SQL，就能生成原子性的UPDATE语句，同时保持强类型的优势：

await dbContext.Persons
    .Where(p => p.Id == personId)
    .ExecuteUpdateAsync(p => p.SetProperty(b => b.Balance, b => b.Balance + amount));

它的底层逻辑和原生SQL完全一致，同样是让数据库执行原子性的余额累加，避免并发问题。

2. 乐观并发控制+冲突重试 #

如果更新余额前需要做额外业务校验（比如检查余额不能为负、符合特定业务规则），可以用EF Core的乐观并发控制：

• 给Person实体添加并发令牌：比如标记[Timestamp]属性的byte[]字段，或者用[ConcurrencyCheck]标记Balance字段。
• 先查询实体到内存，完成业务校验后修改Balance，再执行更新。此时EF Core会自动在UPDATE语句中加入并发令牌的条件，例如：

  UPDATE Person SET Balance = @newBalance WHERE Id = @id AND ConcurrencyToken = @oldToken
  

• 如果期间有其他请求修改了该记录，数据库会返回0行受影响，EF Core会抛出DbUpdateConcurrencyException。此时可以捕获异常，重新读取最新的Balance值，再次校验并更新，或者提示用户存在并发冲突。

总结 #

• 单纯的余额累加场景：优先选择原生SQL或ExecuteUpdate，直接利用数据库原子操作，简单高效。
• 需要前置业务校验的场景：采用乐观并发控制+冲突重试，既能完成业务逻辑，又能处理并发冲突。

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