基于版本号的 MySQL 乐观锁实现机制
在 MySQL 5.7 的 InnoDB 引擎中，若事务隔离级别设为 REPEATABLE-READ，虽然读操作可并发进行，但写操作仍需获取行级排他锁。然而，在高并发场景下，多个事务仍可能基于同一旧值执行更新，导致后提交的事务覆盖前者的修改，引发数据不一致问题。
乐观锁核心原理
乐观锁通过引入版本号字段（如 version 或 data_version）实现并发控制。更新时不仅校验主键，还校验当前版本号是否与读取时一致。若一致则更新数据并递增版本号；否则更新失败，由应用层决定重试或报错。
以订单表 order 为例，初始数据如下：
| id | 1 |
| order_no | 123456 |
| price | 5 |
| version | 0 |
两个并发事务均执行以下逻辑：
- 查询：SELECT * FROM order WHERE id = 1
- 更新：UPDATE order SET price = 1, version = version + 1 WHERE id = 1 AND version = 0
由于 InnoDB 行锁机制，两个 UPDATE 不会真正"同时"执行。先执行者成功将 version 改为 1；后执行者因条件 version = 0 不成立而影响行数为 0，从而感知到冲突。
死锁规避策略
当多个事务以不同顺序更新多行时，可能形成死锁。例如：
- 事务 A：先更新 id=1，再更新 id=2
- 事务 B：先更新 id=2，再更新 id=1
若两者交错持有对方所需资源，则陷入死锁。解决方法是统一更新顺序——所有事务按相同规则（如主键升序）锁定行，避免循环等待。
实战案例：商品销量更新
考虑销量表 goods_sale：
| 字段 | 类型 | 说明 |
|---|---|---|
| goods_sale_id | VARCHAR(32) | 主键 |
| goods_id | VARCHAR(32) | 商品 ID |
| count | INT | 销量 |
| data_version | INT | 版本号，默认 0 |
初始销量为 100。两个事务同时执行 addCount(100)，期望结果为 300，但若无并发控制，实际结果可能仅为 200。
错误实现（无乐观锁）
@Service
@Transactional
public class GoodsSaleService {
@Autowired
private GoodsSaleDao dao;
public void addCount(String goodsId, Integer increment) {
GoodsSale sale = dao.selectByGoodsId(goodsId);
if (sale == null) throw new RuntimeException("记录不存在");
sale.setCount(sale.getCount() + increment);
int updated = dao.updateCount(sale);
if (updated == 0) throw new RuntimeException("更新失败");
}
}对应的 MyBatis 更新语句未包含版本校验：
<update id="updateCount">
UPDATE goods_sale
SET count = #{record.count}
WHERE goods_sale_id = #{record.goodsSaleId}
</update>正确实现（带乐观锁）
修改更新 SQL，加入版本号比对与递增：
<update id="updateCount">
UPDATE goods_sale
SET count = #{record.count},
data_version = data_version + 1
WHERE goods_sale_id = #{record.goodsSaleId}
AND data_version = #{record.dataVersion}
</update>服务层配合自旋重试逻辑（伪代码）：
public void addCountWithRetry(String goodsId, int increment) {
int maxRetries = 3;
for (int i = 0; i < maxRetries; i++) {
GoodsSale current = dao.selectByGoodsId(goodsId);
if (current == null) throw new RuntimeException("记录不存在");
current.setCount(current.getCount() + increment);
int result = dao.updateCount(current);
if (result > 0) return; // 成功
// 否则短暂休眠后重试
Thread.sleep(10);
}
throw new RuntimeException("多次重试仍失败");
}该方案利用数据库原子性保证版本检查与更新的一致性，仅在冲突发生时重试，适用于冲突概率低的场景，显著优于全局同步锁或分布式锁的性能开销。
