悲观锁通过加锁防止冲突，适合高并发写场景；乐观锁依赖版本控制，适合读多写少场景，二者根据业务权衡使用。

在mysql中，乐观锁和悲观锁是两种不同的并发控制策略，用来解决多线程或多事务环境下对同一数据的读写冲突。它们不是mysql内置的锁类型，而是设计层面的思想，通过不同的机制来实现。

悲观锁：假设冲突总会发生

悲观锁认为：只要不加锁，就可能发生数据冲突。因此，在操作数据前，先加锁，确保整个操作过程中数据不会被其他事务修改。

在MySQL中，通常通过select … for UPDATE或SELECT … LOCK IN SHARE MODE来实现悲观锁，这些语句只能在REPEATABLE READ或更高隔离级别下生效，并且需要开启事务。

使用场景举例：

• 用户下单扣减库存时，先查询库存，再更新。为防止超卖，可在查询时加锁：

 START TRANSACTION; SELECT stock FROM products WHERE id = 1 FOR UPDATE; -- 检查库存是否足够 UPDATE products SET stock = stock - 1 WHERE id = 1; COMMIT; 

此时其他事务无法同时对该行进行读写（直到当前事务提交），从而保证数据一致性。

乐观锁：假设冲突很少发生

乐观锁认为：大多数情况下不会发生冲突，所以不加锁。在更新时才检查数据是否被他人修改过。如果被改了，就放弃或重试。

实现方式通常是给表加一个版本号字段（version）或时间戳字段。每次更新时，检查版本是否匹配，同时更新版本号。

谱乐AI

谱乐AI，集成 Suno、Udio 等顶尖AI音乐模型的一站式AI音乐生成平台。

150

查看详情

示例：

• 表结构包含 version 字段：

 ALTER TABLE products ADD COLUMN version INT DEFAULT 0; 

• 更新时判断版本：

 UPDATE products  SET stock = stock - 1, version = version + 1  WHERE id = 1 AND version = 2; 

如果返回影响行数为0，说明版本不匹配，数据已被其他事务修改，当前操作需重试或报错。

两者对比与选择

悲观锁适合：

• 写操作频繁、并发冲突高的场景
• 一旦发生冲突代价较大（如金融交易）
• 能接受一定性能损耗（因为长时间持有锁）

乐观锁适合：

• 读多写少的场景
• 冲突概率低，追求高并发性能
• 可以容忍失败后重试

注意：乐观锁的“检查-更新”必须是原子操作，不能拆成两个SQL，否则会失去意义。

基本上就这些。理解它们的关键是：悲观锁提前预防，牺牲效率保安全；乐观锁事后校验，提升并发但可能失败。根据业务场景权衡使用即可。