如何控制并发更新冲突_mysql乐观锁方案_技术教程

乐观锁通过版本号或时间戳校验实现无锁并发控制，适用于读多写少场景；更新时以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 表示已被他人抢先更新，需重试或提示用户。

以 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 或分布式锁，乐观锁更适合状态流转类操作（如订单状态从“待支付”→“已支付”）。