乐观锁通过版本号或时间戳校验实现无锁并发控制，适用于读多写少场景；更新时以version为条件，影响行为0则需重试；注意version递增、避免跨事务复用、初始值统一，不适用于强一致性金融场景。
MySQL 中控制并发更新冲突，乐观锁是一种轻量、高效的方式，适合读多写少、冲突概率低的场景。它不依赖数据库锁机制，而是通过版本号或时间戳校验数据是否被其他事务修改过，避免阻塞，提升并发性能。
核心原理：用版本字段做更新条件
在表中增加一个 version（整型）或 updated_at（时间戳）字段，每次更新时带上该字段的旧值作为 WHERE 条件。只有当前记录的 version 与查询时一致，UPDATE 才会生效；否则影响行为为 0 行，应用层据此判断更新失败。
- 建表示例：
CREATE TABLE account (id BIGINT PRIMARY KEY, balance DECIMAL(10,2), version INT DEFAULT 0); - 更新语句：
UPDATE account SET balance = 100, version = version + 1 WHERE id = 1 AND version = 5; - 执行后检查 affected rows：为 1 表示成功；为 0 表示已被他人抢先更新，需重试或提示用户。
Java 应用中典型实现流程
以 MyBatis + Spring 为例，配合 @Version 注解或手动传入 version 参数，确保业务逻辑闭环。
- 查询时获取当前 version：
Account account = accountMapper.selectById(1); // 含 version 字段 - 业务处理后发起带校验的更新：
int rows = accountMapper.updateWithVersion(account.getId(), account.getBalance(), account.getVersion()); - 判断 rows == 0 时，可抛出自定义异常（如 OptimisticLockException），由上层决定重试、合并或提示“数据已被修改”。
注意事项与常见坑点
乐观锁不是银弹，实际使用需规避几个典型问题：
-
version 必须在每次更新时递增：不能固定值，也不能漏加
version = version + 1，否则校验失效。 - 避免跨事务复用 version 值：从 DB 查出 version 后长时间停留（如用户编辑 5 分钟），再提交易失败，应结合前端防重复提交或服务端缓存最新 version。
-
注意 NULL 和初始值：version 初始设为 0 或 1 要统一，WHERE 条件中不要用
IS NULL比较，除非显式允许空值语义。 - 不适用于强一致性要求的金融扣款等场景：此时建议结合 SELECT ... FOR UPDATE 或分布式锁，乐观锁更适合状态流转类操作（如订单状态从“待支付”→“已支付”）。
替代方案对比：乐观锁 vs 悲观锁
悲观锁（如 SELECT ... FOR UPDATE）在事务开始就加锁，简单直接但容易引发等待和死锁；乐观锁无锁，吞吐高，但需要应用层处理失败重试逻辑。
- 乐观锁适用：点赞数、阅读量、订单状态变更、配置项更新等冲突少、可接受重试的场景。
- 悲观锁适用：库存扣减、账户余额实时转账等必须串行、不允许脏读/幻读的关键路径。
- 混合策略也常见：先乐观更新，失败后降级为悲观锁重试一次，兼顾性能与可靠性。
