冲突概率高时优先用悲观锁，如秒杀扣库存需SELECT ... FOR UPDATE加行锁，避免重试开销；读多写少场景用乐观锁，如商品详情页通过version字段校验更新；混合策略按操作粒度拆分，确保索引命中、事务显式控制及隔离级别适配。
冲突概率高时，优先用悲观锁
写操作频繁、多个事务反复争抢同一条记录（比如秒杀扣库存、订单状态流转），乐观锁会触发大量重试，反而拖慢整体吞吐。这时 SELECT ... FOR UPDATE 能提前阻塞竞争者，把冲突控制在加锁阶段，避免无效计算和反复回滚。
- 必须确保查询条件命中索引或主键，否则可能升级为
table lock，整个表被锁死 - 事务要显式开启（
BEGIN）且及时提交（COMMIT），否则锁长期持有，引发连接堆积 - 注意死锁风险：多个事务按不同顺序访问多行时，容易触发
Deadlock found when trying to get lock
读远多于写的场景，乐观锁更合适
像商品详情页、用户资料展示这类接口，更新极少但并发读极高，用版本号（version）或时间戳做乐观锁，能完全避免锁等待，数据库压力更小。
- 更新语句必须带校验条件：
UPDATE table SET x=y, version=version+1 WHERE id=1 AND version=5 -
version字段建议用INT UNSIGNED，避免溢出；初始值设为 0 或 1，不要留空 - 应用层需处理
affected rows == 0的情况——不是失败，而是版本不匹配，应重试或提示“数据已被修改”
混合使用是常见现实选择
一个业务流程里，不同环节对一致性的要求不同。比如下单流程：查库存用乐观锁（快速响应），扣减库存用悲观锁（强一致性），生成订单又可回归乐观（幂等写入）。
- 不要全局统一锁策略，而要按字段/操作粒度拆分：高频读字段加
version，核心写字段走FOR UPDATE - 注意隔离级别影响：
READ COMMITTED下FOR UPDATE只锁命中行；REPEATABLE READ下可能额外加gap lock，影响范围更大 - MyISAM 引擎不支持行级锁，
FOR UPDATE会退化为表锁，务必确认引擎是InnoDB
最容易被忽略的细节：锁生效的前提条件
SELECT ... FOR UPDATE 看似简单，但漏掉任一条件就等于没锁：
- 不在事务内执行 → 自动提交后立即释放锁，失去意义
- 查询未命中任何记录 → 不加任何锁（
id = -1这种情况不会阻塞后续FOR UPDATE） - WHERE 条件无索引 → 触发全表扫描，InnoDB 升级为
table lock，性能雪崩 - 客户端连接超时或异常断开 → 锁不会自动释放，依赖 InnoDB 的
innodb_lock_wait_timeout和事务超时机制
版本号字段如果被业务代码绕过直接更新（比如 ORM 的 save() 忽略 version 检查），乐观锁就形同虚设。锁机制本身不保证安全，只提供工具，最终靠设计和落地细节兜底。
