Oracle乐观锁必须用VERSION字段而非时间戳，因SYSDATE在事务中为常量，无法区分并发顺序；VERSION需为NUMBER(19)类型、默认值0、应用层显式递增，禁用触发器和VARCHAR2；MyBatis须手动添加AND VERSION = #{version}条件并校验影响行数；JPA @Version字段须用Long映射NUMBER(19)，禁用Integer；批量更新不可共用单个version值，须逐条校验或改用悲观锁。

Oracle乐观锁为什么必须用VERSION字段而不是时间戳

因为oracle事务隔离级别下，sysdate或systimestamp在单个sql语句执行过程中是常量，同一事务内多次调用返回相同值，无法区分并发更新顺序。而number类型的version字段由应用显式递增，能真实反映修改次数。

实操建议：

Java Api Extractor

从 Java 项目中提取 Controller 层接口定义为 JSON 数据。

下载

• VERSION字段类型必须为NUMBER(19)或类似整型，避免使用VARCHAR2——JDBC驱动对字符串版本号的自增逻辑不可靠
• 建表时给VERSION设默认值0：VERSION NUMBER(19) DEFAULT 0 NOT NULL
• 不要依赖数据库触发器自动更新VERSION，这会绕过应用层的乐观锁校验逻辑

MyBatis中updateByPrimaryKeySelective如何安全集成乐观锁

MyBatis原生不校验版本号，必须手动改写SQL并检查影响行数。直接调用updateByPrimaryKeySelective会覆盖旧值，彻底失效乐观锁。

实操建议：

• 在标签里显式追加AND VERSION = #{version}条件
• Java层判断SqlSession.update()返回值是否等于1，不等于则抛OptimisticLockException
• 示例SQL片段：

  <update id="updateWithVersion" parametertype="map">
    UPDATE user SET name = #{name}, VERSION = VERSION + 1 
    WHERE id = #{id} AND VERSION = #{version}
  </update>

Spring Data JPA的@Version注解在Oracle上要注意什么

@Version本身是JPA标准，但Oracle对NUMBER字段的精度处理和Hibernate的默认映射存在隐式转换风险，容易导致“更新了0行”却不报错。

实操建议：

• 实体类中@Version字段必须用Long（对应Oracle NUMBER(19)），禁用Integer——Oracle NUMBER超出INT范围时会截断
• 配置spring.jpa.hibernate.use-new-id-generator-mappings=false，避免Hibernate 5.5+默认启用的UUID主键策略干扰版本字段行为
• 确保DDL中VERSION列无NULL约束且有默认值，否则Hibernate插入时可能因NULL版本号导致首次更新就失败

批量更新场景下乐观锁失效的典型表现和规避方式

用IN子句批量更新多条记录时，如果只传一个version值，Oracle会用该值匹配所有行，只要其中一行版本吻合就执行更新，其余行被静默覆盖。

实操建议：

• 禁止对批量操作使用单VERSION参数，必须拆成逐条带校验的更新，或改用数据库端游标循环（性能换安全性）
• 若必须批量，改用FOR UPDATE SKIP LOCKED配合SELECT ... FOR UPDATE先查再更，但这已属于悲观锁模式
• 日志中重点监控update返回行数与预期不符的情况，比如期望更新3行却只返回1——大概率是版本校验漏过了

版本号不是写上去就自动生效的，它依赖每次UPDATE语句里那个AND VERSION = ?条件真正参与执行计划。少一个等号，就等于没锁。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南