MySQL乐观锁与悲观锁实战：原理、实现与面试要点

1. 项目概述：面试的这一问，考的不是两个名词

面试中被问到“MySQL 乐观锁与悲观锁怎么实现”，几乎是后端岗位的必考题。这个问题看似只有两个名词，但它背后牵出来的是一整套并发控制体系：事务隔离级别、索引与行锁的关系、UPDATE 语句的加锁行为、死锁与重试机制。很多同学能背出“乐观锁是版本号，悲观锁是 for update”，但面试官一追问“索引没走会锁全表吗”“重试策略怎么设计”“ABA 问题怎么解决”，就接不上了。

这篇内容不是干巴巴的概念复读，而是站在实际项目落地的角度，把两把锁的底层原理、可执行的操作步骤、踩坑案例和面试追问话术一次讲透。适合正在准备面试的 Java/PHP/Go 开发者，也适合有几年 CRUD 经验、想系统梳理并发控制逻辑的从业者。看完之后，你不仅能答出实现方式，还能说出面试官最想听到的“为什么”和“在什么场景下用哪个”，这恰恰是区分普通候选人和有实战经验候选人的关键分水岭。

关于乐观锁和悲观锁，一句话先说清楚它们的设计哲学：悲观锁默认并发冲突一定会发生，所以提前把数据锁住；乐观锁默认并发冲突大概率不会发生，所以只在提交数据时检查版本是否变化。理解了这两句话，剩下的实现细节就是在围着“如何锁”和“如何检查”做文章。

2. 悲观锁的实现与底层细节

2.1 悲观锁的加锁范围：行锁、表锁、间隙锁分别锁住什么

悲观锁在 MySQL 中最直白的实现就是 SELECT ... FOR UPDATE，但这条语句到底锁住了什么，取决于查询条件是否走索引、走的是哪种索引。

• 走主键索引或唯一索引：锁定的是具体的索引记录，也就是行锁。例如 SELECT * FROM product WHERE id = 10 FOR UPDATE，锁住的只有 id=10 这一行，其他业务通过 id=5 查询时完全不受影响。
• 走普通索引（二级索引）：MySQL 会先锁二级索引记录，再回表锁主键索引记录，仍然是行级锁。这里有个细节，二级索引上的等值查询如果命中了多条记录，会锁住所有命中的行。
• 不走索引或者优化器放弃索引：这是最危险的场景。InnoDB 会退化为对全表的记录逐行加锁，本质上等同于表锁。并发一高，所有操作全部串行化，响应时间直接飙升，甚至会造成大量锁等待超时。
• 范围查询条件下：InnoDB 的 SELECT ... FOR UPDATE 会触发间隙锁（Gap Lock）或临键锁（Next-Key Lock），锁住的不只是已有记录，还有记录之间的间隙。间隙锁的作用是阻止其他事务在这个范围内插入新数据，防止幻读，但它也是死锁的高发区。

从表面上看，悲观锁的语义很简单——“我锁住了这条数据，别人就不能动”，但在 MySQL 内部，加锁的行为要远比“锁一行”复杂得多。所以，面试中如果面试官问“for update 锁的是什么”，回答“锁行”只能算勉强及格，能说出“锁的范围取决于是否走索引和语句类型”才是加分项。

2.2 悲观锁的标准实现：一个完整可运行的 SQL 操作流程

悲观锁不是单独一条语句就能生效的，它必须依赖事务。下面是一段最常用的悲观锁扣减库存的标准操作，我在实际项目中多次使用过这个模板：

sql复制-- 1. 开启事务
START TRANSACTION;

-- 2. 查询库存并加排他锁，注意一定要走主键索引
SELECT stock FROM product WHERE id = 1 FOR UPDATE;

-- 3. 在业务代码里判断库存是否够用，并计算出新库存
-- 比如 Java 代码中：if (stock < buyCount) { throw new RuntimeException("库存不足"); }

-- 4. 执行更新
UPDATE product SET stock = stock - 5, version = version + 1 WHERE id = 1;

-- 5. 提交事务，锁在此刻释放
COMMIT;

这里有几个非常关键的细节，漏掉任何一个都会出大问题：

第一，必须在事务中执行，因为 FOR UPDATE 的锁要等到事务提交或回滚才会释放。如果不在事务里，语句执行完就自动提交了，锁根本起不到保护后续操作的作用。

第二，查询和更新之间要做业务判断。悲观锁的价值在于，它保护的是一个完整的“读-判断-写”操作流程。如果先 SELECT 拿数据，然后在业务代码里做复杂校验，再执行 UPDATE，这中间如果其他事务改了数据，就会出问题。而 FOR UPDATE 一旦锁住了行，其他事务的 UPDATE、DELETE、加锁读都会被阻塞，直到当前事务提交。

第三，别在应用层把事务范围拉得太长。锁持有时间越长，其他事务等待的时间就越久。现实中很多线上故障都源于开发者在事务里执行了远程 RPC 调用，一个接口耗时 2 秒，这把锁就被抱着 2 秒不放，整个系统并发能力直线下降。

2.3 悲观锁在真实项目中会遇到的三个高频问题

问题一：死锁

两个事务各自持有一把锁，又同时去抢对方手里的锁，就会出现死锁。比如事务 A 锁了 id=1 再去锁 id=2，事务 B 锁了 id=2 再去锁 id=1。InnoDB 会检测到死锁并自动回滚其中一个事务，但你的业务代码如果没有对“事务被回滚”做捕获和重试，用户就会直接看到错误。

规避死锁最有效的方法是：多个事务如果涉及多行数据，尽量按相同的顺序加锁。比如要操作 id=1 和 id=2 两行数据，所有事务都先锁 id=1 再锁 id=2，这样就不会形成循环等待。

问题二：锁等待超时

mysql 的默认锁等待超时时间是 50 秒。如果某个事务长期持锁不释放，其他事务在 50 秒后会报 Lock wait timeout exceeded。排查这种问题时，优先查 information_schema.innodb_trx、innodb_lock_waits 这些系统表，找出谁在阻塞谁，然后干掉长时间未提交的事务。

问题三：关闭自动提交导致的锁不释放

很多开发者在写测试脚本时把 autocommit 关了，然后执行了一条 SELECT ... FOR UPDATE，没有显式提交或回滚，锁就被一直占着。这个问题在生产环境中也偶有出现，通常是因为异常处理里漏了 rollback 操作。保险的做法是，在事务代码里用 try-catch-finally 保证出错一定回滚，或者用 Spring 的 @Transactional 之类的声明式事务，让框架来处理提交和回滚。

3. 乐观锁的实现与底层细节

3.1 乐观锁的核心机制：版本号、CAS、时间戳

乐观锁不依赖数据库的锁机制，而是通过在数据层面记录一个版本信号，在更新时比对版本信号来判断数据有没有被其他事务改过。

最常见的三种实现信号：

• 版本号：表中加一个 version 字段，每次更新时 version = version + 1。更新语句的 WHERE 条件中带上旧的版本号，如果影响行数为 0，说明版本已被别人改过，需要重试。
• 时间戳：用 update_time 字段作为版本信号，更新时把 update_time 带入 WHERE 条件。和版本号相比，时间戳的粒度不如 int 严格，因为在高并发下可能在同一毫秒内多次更新，但大多数业务场景下够用。
• CAS 思想：不引入额外字段，直接在 UPDATE 语句中用业务字段本身做条件校验。比如扣库存时用 WHERE stock >= 需要扣减的数量，靠的是数据库层面受影响行数来判断是否冲突。这就是 Compare And Swap 在 SQL 中的体现。

我要特别强调一下，乐观锁本质上不是数据库锁，而是业务层的并发控制策略。它用 UPDATE 语句的原子性来保证“版本比较+版本更新”是原子操作，从而避免并发覆盖。

3.2 乐观锁的标准实现：三行 SQL 模板加 Retry 回路

乐观锁的套路非常固定，以版本号为例，核心流程如下：

sql复制-- 1. 读取数据，拿到当前的 version
SELECT id, name, stock, version FROM product WHERE id = 1;

-- 2. 业务代码里计算出新值后执行更新，带上版本号条件
UPDATE product 
SET stock = 95, version = version + 1 
WHERE id = 1 AND version = 7;

第二步执行后，如果影响行数为 1，说明版本没有冲突，直接提交；如果影响行数为 0，说明版本已经被其他事务更新，当前事务的更新是建立在过期数据之上的，必须回滚并重试。

在 Java 里的重试逻辑通常这样写：

java复制for (int retryCount = 0; retryCount < 3; retryCount++) {
    Product product = productMapper.selectById(1);
    int rows = productMapper.updateWithVersion(1, product.getVersion(), newStock);
    if (rows == 1) {
        return success;
    }
}
throw new RuntimeException("更新失败，已重试3次");

这里有一个实战中非常重要的优化方向：重试时不要继续用第一次查询的 version，而要重新 SELECT 一次拿到最新版本。因为第一次的 version 已经过期了，再拿旧版本去重试只会无限失败。很多人在项目里踩过这个坑。

另外补充一个细节：如果项目用的是 MyBatis Plus 这类框架，它内置了乐观锁插件，原理就是自动帮你把 version 拼进 UPDATE 的 SET 和 WHERE 条件中。但你要理解底层原理，这样在框架失效或遇到复杂 SQL 时才能快速定位问题。

3.3 乐观锁的使用边界：ABA 问题和无效重试

乐观锁虽然轻量，但在高并发写入场景中并不总是最优解。

先说 ABA 问题。从理论上来讲，如果版本信号变化过程是 1 -> 2 -> 1，事务在读取时看到的是 version=1，另一个事务把版本改成了 2，然后又改回了 1，那么当前事务在提交时发现 version 还是 1，就认为数据没有被修改过。但在使用 int 递增版本号时，version 从 1 改成 2 再改回 1，如果是普通的版本号字段，确实会检查不出来。所以推荐版本号只增不减，用物理字段的单调递增来避免 ABA。时间戳字段天然具备单调性，所以不会出现 ABA 问题，这也是很多系统倾向于使用 update_time 做乐观锁信号的原因。

再说 冲突过高时的无效重试。当一个热点数据被大量并发更新时，乐观锁的重试几乎没有意义，因为每次重试读取到的版本号都可能是新的，然后再次更新再次失败，白白消耗数据库 CPU 和网络 IO。这种场景下，乐观锁的重试上限要合理设置，比如 3 到 5 次就放弃，改走人工处理或其他降级方案。

还有一点容易被忽略：乐观锁适用于“读多写少”的场景，并不适合“先读后写、业务计算高度依赖旧值”的复杂事务。比如转账场景中，余额扣减不仅要校验版本，还要校验余额不能为负，如果只靠版本号更新，业务判断做得不够严谨，很容易出现负数。这种情况下，要么用 CAS 把余额条件也写进 UPDATE，要么干脆用悲观锁，逻辑更清晰。

4. 乐观锁与悲观锁的选型：别背八股文，要按场景选

4.1 两把锁的关键特性对比

这个对比表基本就是面试官考察“你懂不懂选型”的评分标准。不要把乐观锁说得百无禁忌，也不要把悲观锁说得一无是处，关键是结合场景给出选择理由。

4.2 场景化拆分：什么时候用悲观锁，什么时候用乐观锁

资金转账、账户余额操作，优先选悲观锁。转账操作要求强一致性，而且余额的计算必须基于最新值，一旦并发写导致余额被覆盖，后果很严重。用 SELECT ... FOR UPDATE 锁住账户行，再更新余额，逻辑直观且不容易出错。

电商秒杀、限量抢购，根据冲突比选型。如果商品库存只有 100 件，但同时有 1 万人参与抢购，这是典型的写冲突远超预期，悲观锁会让 9900 人都在排队等锁，直接用悲观锁会拖垮数据库。相比之下，CAS 风格的乐观锁更合适，库存字段用 UPDATE ... SET stock = stock - 1 WHERE id = ? AND stock > 0，数据库的行锁只会短暂地存在于 UPDATE 执行期间，冲突激烈时大量流量会在应用层拿到 0 行影响数后快速返回失败，用户反馈更平滑。

点赞数、浏览数、计数器这类高频非核心字段，用乐观锁或直接原子更新。比如点赞数，不需要精确到分毫不差，可以用 UPDATE ... SET like_count = like_count + 1 这种原子自增，连版本号都不用。

多表关联事务，谨慎用乐观锁。如果一次操作要更新主表和子表多张表，乐观锁校验版本号只针对某一行的字段，很难覆盖整批数据的并发冲突。这种场景下悲观锁配合事务的加锁顺序，反而更可靠。

4.3 我的选型经验：不要盲目追求“高性能方案”

我见过太多开发者在项目里为了“显得先进”，把库存操作一律改成乐观锁，结果业务上出现超卖或者更新失败率过高，最后不得不回退到悲观锁。

这里想说的经验是：乐观锁在降低数据库锁竞争上的确有优势，但它把冲突处理的责任推给了业务方，重试逻辑、失败降级、并发补偿都要自己写。如果你所在团队对数据一致性要求极高，且没有完善的监控和兜底机制，那悲观锁往往比乐观锁更容易维护。

不同场景下，锁不是非黑即白。很多成熟系统是混合用的，比如查询用快照读不加锁，核心库存用悲观锁，操作日志用乐观锁。面试时能主动说出这种组合策略，会让面试官觉得你确实做过高并发设计，而不是只在背概念。

5. 面试追问实战：这道题想拿高分，必须答出这几个细节

5.1 高频追问汇总与参考回答

追问一：SELECT ... FOR UPDATE 没走索引，会锁全表吗？

技术上是会锁全表记录的。因为 InnoDB 的行锁是通过索引项实现的，如果查询条件扫描了全表，那存储引擎会对扫描到的每一行加锁。所以在生产环境里，必须保证 FOR UPDATE 的查询条件走索引，否则并发一上来就是灾难。

追问二：FOR UPDATE 和 UPDATE 直接执行的区别是什么？

两者都会加排他锁，但 UPDATE 语句在执行时是一个原子操作，如果业务判断需要依赖查询到的旧值，直接 UPDATE 无法做到“先读后写”的中间步骤，FOR UPDATE 则通过显式加锁让“读-判断-写”整个过程都处于受保护状态。

追问三：乐观锁的版本号更新一定会成功吗？

不一定。如果业务里除了当前事务，还有其他逻辑在更新同一条数据的其他字段，那么版本号更新也可能被并发事务的版本递增所影响。此外，如果 SQL 没有把 version 作为 WHERE 条件，或者 set 中没有递增 version，那版本号就形同虚设了。

追问四：隔离级别对这两种锁有什么影响？

悲观锁本身依赖锁机制，与隔离级别关系不大，但间隙锁和死锁的行为在 RC（Read Committed）和 RR（Repeatable Read）下表现不同。RC 下没有间隙锁，所以死锁概率通常更低。乐观锁则是靠业务条件，理论上在任何隔离级别下都能工作，但如果想要“当前读”还是“快照读”的行为可预期，建议在 RC 下使用，因为 RR 下普通的 SELECT 是快照读，和业务代码里拿到的旧版本可能不一致，容易搞混逻辑。

5.2 面试现场手写实现模板

面试官让你现场写实现时，不要上来就写代码，先给出“设计要点”的口头说明，再写代码，会大幅加分。

先说悲观锁的设计要点：“我会在事务中先查询加锁，再执行业务判断并更新，最后提交释放锁，同时保证查询走主键索引，避免锁全表。”

然后是核心代码：

java复制@Transactional
public boolean deductionStock(Long productId, Integer count) {
    // 查库存并加悲观锁，只锁这一行
    Product product = productMapper.selectByIdForUpdate(productId);
    if (product == null) {
        throw new RuntimeException("商品不存在");
    }
    if (product.getStock() < count) {
        throw new RuntimeException("库存不足");
    }
    int rows = productMapper.updateStock(productId, product.getStock() - count);
    return rows == 1;
}

对应 SQL：

sql复制SELECT * FROM product WHERE id = ? FOR UPDATE;
UPDATE product SET stock = ? WHERE id = ?;

再写乐观锁版本。面试时演示乐观锁，一定要画出重试这个动作，否则只写一条 UPDATE 太单薄：

java复制public boolean deductionStockByOptimisticLock(Long productId, Integer count) {
    for (int i = 0; i < 3; i++) {
        Product product = productMapper.selectById(productId);
        if (product == null || product.getStock() < count) {
            return false;
        }
        int rows = productMapper.deductStockWithVersion(
                productId, product.getStock() - count, product.getVersion());
        if (rows == 1) {
            return true;
        }
        // rows == 0 说明 version 已变化，继续重试
    }
    return false;
}

sql复制UPDATE product 
SET stock = ?, version = version + 1 
WHERE id = ? AND version = ?

这段现场手写能体现两点：第一，你知道乐观锁依赖受影响行数判断成功与否；第二，你有一套完整的重试策略而非一次失败立即报错。

5.3 我是面试官，会更看重这些加分的思考

在真实的面试场景中，如果候选人讲完了实现原理和代码，我会紧接着抛出一个开放题：“库存只有 50 件，抢购有 1 万人，你如何设计？”

这个问题的优秀答案不是直接说“用乐观锁”，而是先讲清楚业务目标：不允许超卖，同时让大多数用户尽快得到“已售罄”的反馈。然后再拆解方案：库存扣减可以用乐观锁或原子更新来保证不超卖，但直接在数据库上扛 1 万人并不现实，通常需要前置一层排队或限流，比如 Redis 预扣减、消息队列削峰，数据库只做最终的强一致扣减。

所以说，锁只是并发控制工具中的一环，真正优秀的设计者会把锁放在整个流量链路的正确位置上，知道什么时候应用层拦截，什么时候数据库兜底。你在面试中如果能从这一层去回答，已经超过大多数背概念的候选人了。

基于我多年的面试经验，最后给出两个直接可用的提示。第一，回答锁的问题一定要分场景，不要一上来就说哪个更好，先问清楚业务特征，再给方案，这是架构思维的基本体现。第二，聊到乐观锁一定要把重试策略讲清楚，聊到悲观锁一定要把索引和锁释放讲清楚，这两个细节是区分背答案和真会用的标准。希望这篇内容能帮你在面试中把这两把锁讲出层次感，而不是停留在“版本号对不上就重试”这种表面理解上。