重试前必须重新select最新数据，否则在repeatable read隔离级别下会因读取旧version导致更新失败；需每次重试都开启新事务或清空一级缓存，并叠加变更而非覆盖。
重试前必须重新 SELECT 最新数据
事务内多次 SELECT 不会看到其他事务已提交的更新，这是 MySQL 默认隔离级别 REPEATABLE READ 的行为。如果在同一个事务里反复调用 selectOne() 读取 version，拿到的永远是第一次读到的旧值，导致 UPDATE ... WHERE version = ? 永远不匹配，陷入“幻重试”——表面在重试，实际卡死在旧版本上。
正确做法：每次重试前，必须脱离当前事务上下文（或显式清空一级缓存），重新发起一次独立的 SELECT。常见手段包括：
- 把重试逻辑移出
@Transactional方法，改由外层开启新事务（每次重试都是新事务） - 若必须在事务内重试，需手动清除 MyBatis 一级缓存：
sqlSession.clearCache() - 使用
@Transactional(propagation = Propagation.REQUIRES_NEW)标注重试内部方法，强制新开事务
MyBatis-Plus 的 OptimisticLockerInnerInterceptor 不自动重试
OptimisticLockerInnerInterceptor 只负责在 UPDATE 语句中自动拼接 version 条件和自增逻辑，它不会捕获 0 row affected 并触发重试。失败时只会返回 0，你需要自己判断并处理。
典型错误写法：if (mapper.update(entity) == 0) { retry(); } —— 这里 entity.version 还是旧值，直接重试等于重复失败。
正确流程应为：
- 查出当前记录（含最新
version） - 修改业务字段
- 调用
mapper.update(entity) - 若返回
0，跳回第一步重新查，**不是复用原 entity**
重试次数与退避策略不能忽略
无限制循环重试可能拖垮数据库连接池或触发 Lock wait timeout exceeded。高并发下尤其危险。
建议硬性限制重试次数（如最多 3 轮），并在每次重试间加入短暂延迟：
- 固定延迟：
Thread.sleep(10)（简单场景） - 指数退避：第 n 次重试前 sleep
Math.min(100 * (2 ^ (n-1)), 500)ms - 避免所有请求在同一毫秒重试，可加随机抖动（如 ±5ms）
注意：Spring Retry 的 @Retryable 默认重试是在同一事务内，仍会复用旧数据，必须配合 Propagation.REQUIRES_NEW 使用。
业务层合并变更比覆盖更安全
单纯“查→改→存”在重试过程中容易丢失中间变更。例如两次扣库存请求同时读到 stock=100, version=1，各自扣 1 后都尝试 UPDATE ... SET stock=99, version=2 WHERE version=1，后者必然失败。
更健壮的做法是：重试时读到新记录后，**把本次要做的变更（如 -1）叠加到最新值上**，而不是覆盖整个对象：
- 读到
stock=99, version=2→ 执行UPDATE ... SET stock=98, version=3 WHERE version=2 - 避免业务逻辑耦合在实体类 setter 中，推荐用 SQL 原生表达式更新：
SET stock = stock - 1
这要求你的更新语句不依赖 Java 对象全量赋值，而是明确指定变更字段和运算逻辑。
