选型核心是看变量被并发修改的频率：冲突少用乐观锁，冲突高用悲观锁。乐观锁靠版本号校验、不阻塞读，适用于社交点赞等低冲突场景；悲观锁用select ... for update提前加锁，适用于秒杀、转账等高冲突场景；需关注热点数据写密度而非整体qps，灰度时监控失败率与等待时长，混合策略更常见。

选型核心就一条：看变量被并发修改的频率。冲突少，用乐观锁；冲突高，用悲观锁。不是性能或技术先进性的问题，而是匹配业务真实读写节奏的问题。

冲突低时，乐观锁更轻快

当多个线程/事务大概率不会同时改同一行数据（比如用户资料编辑、文章点赞、订单状态标记），乐观锁靠版本号或时间戳做提交校验，全程不锁表、不阻塞读，吞吐量高、响应快。

• 典型场景：社交类操作（评论更新、关注数+1）、内容管理系统（草稿保存）、非核心库存预扣减
• 关键动作：表里加 version 字段，UPDATE 语句必须带 WHERE id = ? AND version = ?
• 失败后需主动重试（例如 while 循环 + 最大重试次数），不能直接抛错中断业务

冲突高时，悲观锁更稳当

当多个请求极可能争抢同一资源（如秒杀最后一件、账户余额扣款、订单支付锁单），乐观锁会频繁失败重试，反而放大延迟和错误率。此时用悲观锁提前锁定，宁可排队也不乱。

• 典型场景：金融转账、库存强扣减、抢购锁单、订单创建时查重并占位
• 关键动作：在事务内用 SELECT ... FOR UPDATE（行级排他锁），确保后续 UPDATE 不被干扰
• 注意避免长事务——锁持有时间越短越好，否则阻塞面扩大

别只看“读多写少”，要看“谁在写同一行”

表面读多写少，但如果写集中在极少数热点记录（如热门商品ID=1001），那实际冲突频率很高。这时候乐观锁容易雪崩，应倾向悲观锁或引入分段锁、缓存预减等优化手段。

• 判断依据不是总QPS，而是热点数据的写请求并发密度
• 可通过数据库慢日志、锁等待监控（如 information_schema.INNODB_TRX）验证真实冲突情况
• 灰度上线时，重点观察乐观锁的失败率（>5% 就该警惕）、悲观锁的平均等待时长（>100ms 需优化）

混合用法很常见，不是非此即彼

真实系统往往按操作类型或数据层级拆分策略。例如：

• 读库存走缓存（无锁），扣库存走数据库悲观锁（强一致）
• 用户资料页整体用乐观锁，但其中“手机号”字段因校验严格改用悲观锁
• 先用乐观锁尝试更新，失败后降级为悲观锁重试（适合对一致性有兜底要求的场景）