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字段由应用显式递增，能真实反映修改次数。
实操建议：
-
VERSION字段类型必须为NUMBER(19)或类似整型，避免使用VARCHAR2——JDBC驱动对字符串版本号的自增逻辑不可靠 - 建表时给
VERSION设默认值0：VERSION NUMBER(19) DEFAULT 0 NOT NULL - 不要依赖数据库触发器自动更新
VERSION，这会绕过应用层的乐观锁校验逻辑
MyBatis中updateByPrimaryKeySelective如何安全集成乐观锁
MyBatis原生不校验版本号，必须手动改写SQL并检查影响行数。直接调用updateByPrimaryKeySelective会覆盖旧值，彻底失效乐观锁。
实操建议：
- 在
<update></update>标签里显式追加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行”却不报错。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 实体类中
@Version字段必须用Long（对应OracleNUMBER(19)），禁用Integer——OracleNUMBER超出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 = ?条件真正参与执行计划。少一个等号，就等于没锁。
