悲观锁适用于并发写频繁、一致性要求高的场景，核心是“先锁再操作”，通过select ... for update或lock in share mode在事务中加行级锁，防止脏写和丢失更新。
悲观锁适用于并发写操作频繁、数据一致性要求极高的场景，核心思想是“先锁再操作”，避免多个事务同时修改同一行数据导致脏写或丢失更新。
典型使用场景
以下情况适合使用悲观锁：
- 库存扣减：电商下单时需确保商品库存不超卖，例如更新商品表的 stock 字段前加锁
- 账户余额变更：银行转账中对转出/转入账户余额行加锁，防止并发操作引发金额错乱
- 订单状态强制流转：如将“待支付”订单改为“已取消”，需独占该订单记录防止重复处理
- 后台管理中的敏感数据编辑：多人协作系统中，编辑用户权限或配置项时防止覆盖他人修改
SQL 中的实现方式（以 MySQL InnoDB 为例）
悲观锁依赖数据库的行级锁机制，主要通过 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 触发：
- FOR UPDATE：加排他锁（X锁），其他事务无法读写该行（除非读未提交），常用于写操作前锁定
- LOCK IN SHARE MODE：加共享锁（S锁），其他事务可加S锁但不能加X锁，适合读+后续可能更新的场景
- 必须在 显式事务中使用（BEGIN / START TRANSACTION 开启，COMMIT 或 ROLLBACK 结束），否则锁在语句执行完立即释放
- 锁的粒度取决于查询条件是否命中索引：若 WHERE 条件走主键或唯一索引，只锁匹配行；若走全表扫描或非唯一索引，可能锁住多个间隙甚至整张表
注意事项与常见问题
用不好悲观锁容易引发性能瓶颈甚至死锁：
- 避免长事务：持有锁时间越长，并发度越低，应尽量缩短事务内操作，不要在事务中调用外部服务或等待用户输入
- 注意锁顺序：多个事务按不同顺序访问多行数据易导致死锁，建议统一按主键升序加锁
- 确认隔离级别支持：READ COMMITTED 和 REPEATABLE READ 均支持行锁，但 RR 下还涉及间隙锁，需结合业务理解锁范围
- 应用层需处理锁等待超时：MySQL 默认 lock_wait_timeout=50秒，超时抛出异常，业务应捕获并重试或降级
简单示例（库存扣减）
假设扣减商品 ID=100 的库存：
START TRANSACTION; SELECT stock FROM product WHERE id = 100 FOR UPDATE; -- 应用层判断 stock >= 1 UPDATE product SET stock = stock - 1 WHERE id = 100; COMMIT;
该过程确保在 COMMIT 前，其他事务无法修改该商品库存，从而避免超卖。
