MySQL中乐观锁需应用层实现，常用UPDATE...WHERE version=？模式，通过ROW_COUNT()判断是否更新成功；version字段须为INT/BIGINT，禁用TIMESTAMP。
乐观锁怎么在 MySQL 中实现
乐观锁不是数据库的内置机制，而是应用层基于版本号或时间戳的并发控制策略。MySQL 本身不提供 OPTIMISTIC LOCK 语法，必须靠业务逻辑+唯一约束/条件更新来保障。
最常用的是 UPDATE ... WHERE version = ? 模式：
UPDATE account SET balance = balance - 100, version = version + 1 WHERE id = 123 AND version = 5;
执行后检查 ROW_COUNT()（JDBC 中为 executeUpdate() 返回值）：
- 返回 1 → 更新成功，版本已推进
- 返回 0 → 说明
version已被其他事务改过，当前操作冲突失败
注意：字段 version 必须是 INT 或 BIGINT，不能用 TIMESTAMP —— 因为高并发下可能毫秒级重复，导致误判丢失更新。
立即学习“Java免费学习笔记（深入）”；
悲观锁在 MySQL 中用 SELECT ... FOR UPDATE 就够了吗
不够。它只在事务内、且满足特定隔离级别和索引条件下才真正加行锁。常见失效场景比想象中多：
- 没开事务：
SELECT ... FOR UPDATE在自动提交模式下会立刻释放锁，等于没锁 - 查询没走索引：InnoDB 会升级为表锁（尤其是
WHERE条件无索引时），严重拖慢并发 - 使用了非唯一条件：比如
WHERE status = 'pending'，可能锁住所有匹配行甚至间隙，引发锁等待甚至死锁 - 事务过长：锁持有时间越长，阻塞越严重，还可能触发
Lock wait timeout exceeded
正确写法必须包含：BEGIN 显式开启事务 + 精确主键/唯一索引查询 + 尽快提交。
Java 代码里怎么配合 Spring 处理乐观锁失败
不能靠 try-catch Exception 捕获，因为乐观锁冲突不会抛异常，只会返回影响行数为 0。关键是在 DAO 层判断结果并向上抛出自定义业务异常：
int updated = jdbcTemplate.update(
"UPDATE order SET status = ?, version = version + 1 WHERE id = ? AND version = ?",
newStatus, orderId, expectedVersion
);
if (updated == 0) {
throw new OptimisticLockException("Order " + orderId + " has been modified");
}Spring 事务中，建议把重试逻辑放在 Service 层（而非 DAO），并限制重试次数（如最多 3 次），避免无限循环。不要在 @Transactional 方法里直接 while(true) 重试——事务已开启，重复执行仍会读到旧 version。
什么时候该选乐观锁，什么时候必须用悲观锁
选型核心看冲突概率和操作耗时：
- 乐观锁适合：读多写少、修改逻辑快（如状态机流转）、冲突极少（如用户资料更新）
- 悲观锁必要场景：写操作涉及复杂校验+多步更新（如库存扣减+生成订单+冻结积分）、必须强一致性（如银行转账）、或冲突频繁（如秒杀商品库存）
一个常被忽略的点：乐观锁的“失败处理”成本可能比悲观锁更高——如果每次冲突都要查最新数据再重试，网络+SQL 开销叠加，反而更慢。这时候不如一开始就用 SELECT ... FOR UPDATE 把资源稳稳锁住。
