悲观锁假设总会冲突，提前加锁（如FOR UPDATE）；乐观锁假设很少冲突，提交时校验版本号。前者适合写多、强一致场景，后者适合读多、低冲突场景，选择取决于业务特征与失败成本。
悲观锁和乐观锁是SQL数据库中两种核心的并发控制策略，它们解决的是多个事务同时访问同一数据时可能引发的脏读、不可重复读、丢失更新等问题。选择哪种锁，取决于业务场景对一致性、性能和冲突频率的权衡。
悲观锁：假设总会发生冲突，提前加锁
悲观锁在操作数据前就通过数据库的锁机制（如SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE）将数据行或范围“占住”，其他事务必须等待锁释放才能继续。它适合写多读少、冲突概率高、且对数据强一致要求严格的场景，比如银行转账、库存扣减。
- MySQL InnoDB中，FOR UPDATE会在查询的记录上加排他锁（X锁），阻塞其他事务的读写；LOCK IN SHARE MODE加共享锁（S锁），允许其他事务加S锁但拒绝X锁
- 锁的粒度可以是行级（有索引条件时）、页级或表级，实际使用中务必确保WHERE条件命中索引，否则可能升级为表锁
- 需注意死锁风险——多个事务按不同顺序请求锁时容易触发，数据库会自动检测并回滚其中一个事务
- 事务结束后锁自动释放，因此要避免长事务，否则会持续阻塞并发操作
乐观锁：假设很少冲突，只在提交时校验
乐观锁不依赖数据库锁，而是通过版本号（version）或时间戳（timestamp）字段，在UPDATE语句中加入校验条件，确保数据未被他人修改过。它适用于读多写少、冲突概率低的场景，比如文章编辑、用户资料更新。
- 典型实现是在表中增加version INT DEFAULT 0字段，每次更新时用UPDATE t SET name='x', version=version+1 WHERE id=1 AND version=5，若影响行数为0，说明version已变，需重试或提示冲突
- 也可用CHECKSUM或MD5(列值)做一致性校验，但开销略大，且无法覆盖所有字段变更情况
- 应用层需配合重试逻辑（如最多3次），不能简单抛异常；对于前端用户，应给出友好提示而非报错页面
- 乐观锁本身不阻止并发读，因此不会造成阻塞，吞吐量更高，但无法防止幻读，需结合MVCC或其他机制补充
如何选择：看场景，不是看技术偏好
没有绝对优劣，关键看业务特征和可接受的失败成本。
- 高频写入、金额/库存类强一致性操作 → 优先考虑悲观锁，配合短事务和索引优化
- 内容管理、配置类低频更新、用户自助修改 → 更适合乐观锁，体验更顺滑，系统更轻量
- 混合场景可分层处理：例如订单创建用乐观锁，支付扣款环节切到悲观锁保障资金安全
- 无论哪种锁，都建议搭配数据库事务隔离级别（如READ COMMITTED或REPEATABLE READ）协同使用，不能孤立看待
