不是必须，但高并发抢购、秒杀等“读-判-写”场景下，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 分布式锁或数据库唯一约束兜底
实际用的时候，悲观锁不是“开了就行”，而是要盯着事务生命周期、索引有效性、锁等待时间这三点看——很多问题不是锁机制不行，是锁没落在该落的地方。
