乐观锁通过版本号或时间戳在提交时校验数据是否被修改，UPDATE语句必须将版本条件写入WHERE子句并检查影响行数；Redis需用Lua脚本保证原子性；高冲突场景宜改用悲观锁。
乐观锁怎么防止更新丢失，但又不卡住其他事务
乐观锁本质是“先查后验”，靠版本号或时间戳判断数据是否被改过。关键不在加锁，而在提交时校验——UPDATE 语句里必须把版本条件写进 WHERE 子句，否则等于没锁。
- 常见错误：查出
version = 5，更新时却只写SET version = 6 WHERE id = 123，漏掉AND version = 5，导致覆盖别人刚提交的修改 - 正确写法：
UPDATE account SET balance = 100, version = 6 WHERE id = 123 AND version = 5；执行后检查ROW_COUNT()（MySQL）或rowsAffected（JDBC），为 0 就说明冲突了 - 时间戳不如版本号可靠：多个更新在同一毫秒发生时，
updated_at > ?可能漏判；版本号递增天然防重 - 注意 ORM 框架是否真生成带版本条件的 SQL——比如 MyBatis-Plus 的
@Version注解默认生效，但手动写的xml更新语句不会自动加
悲观锁在 MySQL 里怎么写才真正生效
很多人以为 SELECT ... FOR UPDATE 一写就锁表，其实它只锁索引覆盖的行，且依赖事务隔离级别和查询条件是否走索引。不满足条件，可能变成锁表甚至锁不住。
- 必须在显式事务中使用：
BEGIN/START TRANSACTION后执行，否则语句结束立刻释放锁 - 查询条件必须命中索引，否则 InnoDB 会升级为表级间隙锁（
gap lock），阻塞无关记录插入，引发大面积等待 -
SELECT * FROM order WHERE user_id = 123 FOR UPDATE—— 如果user_id没索引，实际锁的是整个聚簇索引，不是你想锁的那几条订单 - 读已提交（RC）下，
FOR UPDATE只锁匹配到的行；可重复读（RR）下还额外加间隙锁，防幻读，但也更容易死锁
Redis 实现分布式乐观锁为什么比数据库更难兜底
Redis 没有原子性的“查+改+校验”指令，GET 和 SET 分两步，中间必然存在窗口期。所以得用 EVAL 或 Lua 脚本把逻辑包进服务端原子执行，否则根本不算乐观锁。
- 典型错误：先
GET stock:1001得到 5，再SET stock:1001 4，中间别人可能已把值改成 3，你覆盖成 4 就错了 - 正确做法：用 Lua 脚本一次性完成比较和更新，例如
EVAL "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('SET', KEYS[1], ARGV[2]) else return 0 end" 1 stock:1001 5 4 - 注意 Redis 集群模式下，
KEYS[1]必须落在同一 slot，否则EVAL报错；单节点没问题，但上线前得确认部署拓扑 - 别依赖
WATCH+MULTI：它只对 key 做乐观检查，一旦 key 被删或 TTL 过期，事务直接失败，业务上很难区分是冲突还是 key 不存在
混合锁策略：什么时候该切悲观，什么时候死守乐观
没有银弹。高冲突场景下硬上乐观锁，重试成本远高于一次加锁开销；而低频更新却用悲观锁，等于主动制造排队瓶颈。
- 适合乐观锁：用户资料修改、配置项开关、积分累加等冲突概率
- 适合悲观锁：库存扣减、抢购、账户资金转账等强一致性要求、冲突频繁的场景；但得配超时机制（
innodb_lock_wait_timeout或应用层tryLock(timeout)），避免无限等待 - 别忽略“伪冲突”：比如两个事务更新同一行的不同字段，乐观锁仍会因版本号变化而拒绝，此时可考虑列级版本（如
balance_version和contact_version分开）或合并更新 - 最麻烦的是跨库/跨服务操作：数据库乐观锁只管自己这摊事，外部系统状态无法原子校验，这时候往往得靠最终一致性 + 补偿事务，而不是硬套锁模型
锁不是越细越好，也不是越早加越稳；真正难的是判断哪一行数据、在哪个时刻、被谁以什么方式改——这些信息藏在业务路径里，不在 SQL 语法里。
