SQL 悲观锁适合哪些业务场景？

不是必须，但高并发抢购、秒杀等“读-判-写”场景下，SELECT ... FOR UPDATE 是最稳妥的选择，需显式事务、索引支持及合理加锁顺序。

库存扣减必须用 SELECT ... FOR UPDATE 吗？

不是“必须”，但高并发抢购、秒杀类场景下，SELECT ... FOR UPDATE 是最稳妥的选择。原因很简单：你要先查库存，再判断是否足够，最后扣减——这三步不能被其他事务插队。如果不用悲观锁，两个事务同时查到“还有 1 件”，都执行 UPDATE，就超卖了。

• 适用前提：业务逻辑是「读-判-写」三步且不可拆分，且一致性优先级高于吞吐量
• 典型错误：在自动提交（autocommit=1）模式下直接执行 SELECT ... FOR UPDATE，锁会立刻释放，起不到保护作用——必须显式 BEGIN/COMMIT
• 注意：InnoDB 要求查询条件命中索引，否则升级为表锁；没走索引的 FOR UPDATE 可能拖垮整张表

银行转账为什么宁可阻塞也不用乐观锁？

因为转账不允许“重试”。乐观锁靠版本号校验，失败后得回滚、重读、重算、再提交——但用户发起一次转账，系统不能返回“请重试”，更不能让余额在中间状态暴露给前端。悲观锁用 SELECT ... FOR UPDATE 锁住两个账户行，整个事务原子执行，失败就是报错，成功就是落库，边界清晰。

• 关键点：强一致性 ≠ 高可用，而是“结果可预期”——阻塞几毫秒，比返回错误码或数据不一致更容易兜底
• 风险提示：锁住 A 账户再锁 B 账户，和锁 B 再锁 A 的事务混在一起，极易死锁；建议统一按主键 ID 升序加锁
• 别忽略隔离级别：REPEATABLE READ 下 FOR UPDATE 默认用临键锁（Next-Key Lock），会锁住间隙，防止幻读，但也可能扩大锁范围

LOCK IN SHARE MODE 和 FOR UPDATE 怎么选？

看后续有没有写操作。LOCK IN SHARE MODE 允许多个事务并发读，但谁都别想改；FOR UPDATE 是独占，连读都不让别人读（除非读已提交隔离级别下允许快照读）。比如审核流程中“查订单状态 → 校验权限 → 更新状态”，前两步只需防写，就可以用共享锁；但只要后面紧跟 UPDATE，就必须上排他锁。

• 常见误用：用 LOCK IN SHARE MODE 查完就 commit，以为锁住了数据，其实一提交锁就释放，别人立刻能改
• 性能差异：共享锁冲突概率低，适合读多写少+需保证读一致性（如报表生成时锁定统计基准）
• MySQL 8.0+ 支持 FOR SHARE 替代 LOCK IN SHARE MODE，语义更直白，建议新项目统一用这个

为什么本地事务里加了锁，线上还是超卖？

大概率是锁没生效，或者锁住了错的对象。最常踩的坑有三个：事务没开启、查询没走索引、锁粒度不对（比如锁了类别ID却想控制商品库存）。

• 验证方法：执行 SELECT * FROM information_schema.INNODB_TRX，看当前活跃事务是否真持有 X 锁；再查 INNODB_LOCK_WAITS 看有没有阻塞链
• 典型陷阱：用 WHERE status = 'pending' 加锁，但 status 没索引 → 全表扫描 → 表级锁 → 整个库存模块卡死
• 进阶注意：如果业务涉及分布式节点（比如多个支付服务实例），单靠 MySQL 悲观锁不够，得配合 Redis 分布式锁或数据库唯一约束兜底

实际用的时候，悲观锁不是“开了就行”，而是要盯着事务生命周期、索引有效性、锁等待时间这三点看——很多问题不是锁机制不行，是锁没落在该落的地方。