悲观锁适合写多冲突高的场景，如库存扣减、账户余额变更等，需在InnoDB事务中用SELECT ... FOR UPDATE实现，要求索引命中且合理设置锁等待超时；乐观锁适用于读多写少场景，通过版本号校验实现，冲突时需应用层重试，二者常混合使用以兼顾性能与一致性。
悲观锁适合写多冲突高的场景
当业务逻辑中频繁出现并发写、且冲突概率高时，SELECT ... FOR UPDATE 是更稳妥的选择。比如库存扣减、订单状态流转、账户余额变更等操作，一旦发生“丢失更新”，后果严重，必须由数据库层强保证一致性。
关键前提是：必须在事务内使用，且引擎为 InnoDB；否则 FOR UPDATE 会退化为表锁甚至无效。常见错误是忘记 BEGIN 或保持 autocommit=1，导致锁不生效或立即释放。
- 加锁条件必须命中索引（主键或唯一索引），否则会升级为表锁，拖垮整个表的并发性能
-
FOR UPDATE只对查询结果集加锁，空结果集不加锁，但事务仍会持有间隙锁（gap lock），可能阻塞插入 - 锁等待超时默认是 50 秒（
innodb_lock_wait_timeout），线上应设为更短值（如 5–10 秒），避免长时间阻塞
乐观锁适合读多写少且重试成本低的场景
乐观锁本质是应用层控制，靠 UPDATE ... WHERE version = ? 这类带条件的更新语句实现。它不依赖数据库锁机制，因此不会阻塞其他读写，吞吐更高——但前提是冲突极少。
典型误用是把乐观锁套在高频写场景（如秒杀下单），结果大量 UPDATE 返回影响行数为 0，业务层反复重试，反而放大数据库压力和响应延迟。
- 版本号字段（
version）必须为整型且初始值 ≥ 0，不能用TIMESTAMP做乐观锁条件，因精度和时区问题易校验失败 - 每次更新必须同时递增版本号：
SET version = version + 1，漏掉会导致后续所有更新都被拒绝 - 应用层必须捕获影响行数为 0 的情况，并决定是重试、降级还是返回失败，不能静默忽略
混合使用比单选更常见
真实业务里很少非此即彼。例如电商下单流程：先用乐观锁查商品库存和版本（快速响应），确认可扣减后，再用 SELECT ... FOR UPDATE 锁住该行做最终扣减和订单生成——前者扛住流量，后者兜底一致性。
另一个常见组合是：用乐观锁做幂等更新（如修改用户昵称），用悲观锁保护资金类操作（如支付成功后的余额变更）。
- 不要在同一个事务里混用两种锁策略操作同一行，容易引发死锁或语义混乱
- 若用 MyBatis 等 ORM，注意
selectForUpdate方法需显式配置fetchSize和timeout，避免连接池耗尽 - 乐观锁的
WHERE条件必须包含全部校验字段（如version+status），否则可能绕过校验
最容易被忽略的细节是锁粒度与隔离级别
SELECT ... FOR UPDATE 在 REPEATABLE READ 隔离级别下会加间隙锁（gap lock），不仅锁住匹配行，还锁住范围，防止幻读。但这也意味着看似无关的插入操作可能被阻塞——比如锁了 id=5，INSERT INTO t VALUES (6) 也可能卡住。
而乐观锁完全不受隔离级别影响，但它要求业务逻辑能容忍“先读后写”窗口期内的并发修改。这个窗口期长短，取决于你从 SELECT 到 UPDATE 的执行耗时，不是毫秒级而是百毫秒级以上就风险陡增。
真正难的不是语法怎么写，而是判断哪一行数据、在什么时刻、被多少个业务路径同时触达——这需要结合慢查日志、锁监控（INFORMATION_SCHEMA.INNODB_TRX）和业务调用链路一起看。
