Dapper怎么处理并发冲突 Dapper乐观锁并发控制策略

Dapper本身不内置乐观锁机制，但能完美配合乐观锁逻辑实现并发安全——关键在于你如何设计SQL、管理版本字段，以及控制更新条件。

Dapper本身不内置乐观锁机制，但能完美配合乐观锁逻辑实现并发安全——关键在于你如何设计SQL、管理版本字段，以及控制更新条件。

加一个版本号字段是前提

数据库表里必须有类似 Version 或 RowVersion 的整数或时间戳字段，每次更新时递增。比如：

• ALTER TABLE Products ADD Version INT NOT NULL DEFAULT 1;
• 实体类中对应属性要映射上，Dapper会自动绑定参数（字段名匹配即可）

• 查询时务必把版本号一起查出来：SELECT Id, Name, Stock, Version FROM Products WHERE Id = @Id

UPDATE语句必须带版本校验

不能直接 UPDATE ... SET Stock = @NewStock，而要加上 WHERE Version = @OldVersion 条件：

• UPDATE Products SET Stock = @Stock, Version = Version + 1 WHERE Id = @Id AND Version = @Version
• 执行后检查 影响行数：如果返回 0，说明版本已变，发生并发冲突
• Dapper的 Execute() 方法直接返回受影响行数，无需额外解析

冲突后重试要可控

检测到更新失败（行数为0）时，不能无限重试。建议用简单策略兜底：

• 最多重试 2～3 次，避免雪崩
• 每次重试前重新 SELECT 最新数据和版本号
• 可加入短延迟（如 Task.Delay(10)），缓解瞬时竞争
• 若仍失败，抛出业务异常（如 OptimisticConcurrencyException），交由上层提示用户“数据已被他人修改”

不依赖框架也能写得干净

Dapper轻量的特点反而利于手动控制乐观锁流程。例如一个库存扣减方法可以这样组织：

• 先查：获取当前 Stock 和 Version
• 判断是否足够：不够就直接返回失败
• 再更新：带版本条件的 UPDATE，检查返回值
• 失败则重查+重算+重试，而不是交给ORM自动处理

基本上就这些。没有魔法，靠的是SQL严谨性和逻辑闭环。