MySQL中的事务隔离级别？

面试记录 2026-09-17

题目：MySQL 中的事务隔离级别？

难度：medium

标签：db/mysql/concepts, mysql/isolation, mysql/transaction, difficulty/medium

评分：⭐⭐⭐☆（3/5）

我的回答

事务隔离级别主要有四种，读未提交、读已提交、重复读和串行化。这个等级隔离级别的限制条件从低到高。最低的读未提交是没有任何事务方面的限制，大家可以读到所有更新的数据，不管事务有没有提交，这时候会存在大量的事务方面的问题，但是效率是最高的。读已提交相对的事务隔离级别高一些，只会读到其他事务提交过的内容，但是也会在事务中会受到其他事务的影响，这时候不会出现脏读，也就是说不会出现读到未提交的内容。处理了脏读，然后可重复读。重复读这块处理的，其实面对的是其他事务提交了，但是其实本质那些事务提交的不应该影响当前事务。这时候它事务第一个 SQL 执行的查询，查到结果跟底下查询的结果可能不一致。可重复读就是应对这种问题，它保证通过 MVCC 的镜像机制，保证当前事务第一次查询跟其他次数查询得到结果是一样的，通过快照机制。但是会可能涉及一个衍生的问题，就是其他数据创建、删除，这时候会导致还是会影响查询数据，这时候就需要串行化。如果最强一致性要求就串行化，串行化了会导致整个锁起来，这个执行完，其他的事务才能执行。保证了完整的数据窗口，但是它的效率太低了。

点评

优点：

• 四种隔离级别名称正确（RU/RC/RR/Serializable），按等级排列正确
• 提到 RC 解决脏读、RR 用 MVCC 快照机制
• 提到串行化的锁代价

不足：

• RC 和 RR 边界混淆：说"RC 处理了不可重复读"是错的——RC 解决脏读，RR 才解决不可重复读
• 未提幻读：RC 和 RR 都可能存在幻读；RR 通过快照读 + 当前读的 next-key lock 缓解但不是完全解决
• 未讲 MySQL 特殊点：RR 使用 next-key lock（行锁 + 间隙锁），RC 用行锁无间隙
• 未提默认级别：MySQL 默认 RR，Oracle 默认 RC
• 未提幻读的三种触发场景：范围查询 + INSERT、当前读、快照+当前读混用

补充：

• RC：每次查询都生成新 ReadView，能看到其他事务提交后的最新值
• RR：事务第一次查询时生成 ReadView，事务期间复用，看不到其他事务期间提交的改动
• Serializable：所有 SELECT 隐式加 S 锁，写入加 X 锁，事务完全串行
• 幻读的四种触发：RC 快照读、RR 快照读 + 当前读混用、RR 范围查询 + 其他事务 INSERT、无 WHERE 条件的大范围 SELECT FOR UPDATE

完整讲解

第一部分：知识重点剖析

核心考点定位：掌握四种隔离级别的定义、解决的读异常、锁机制差异、MySQL 特殊行为。

知识点拆解：

1. 四种隔离级别（低 → 高）：

• READ UNCOMMITTED（RU，读未提交）：能读到其他事务未提交的数据。理论上有，MySQL InnoDB 支持但极少使用
• READ COMMITTED（RC，读已提交）：只能读到其他事务已提交的数据。Oracle 默认
• REPEATABLE READ（RR，可重复读）：同一事务内多次查询结果一致（快照读）。MySQL 默认
• SERIALIZABLE（串行化）：所有事务完全串行执行，性能最差但一致性最高

1. 三种读异常：

• 脏读：读到其他事务未提交的数据（RU 存在，RC 起解决）
• 不可重复读：同一事务内两次读同一行，结果不一致（RC 存在，RR 起解决）
• 幻读：同一事务内两次查询同一范围，第二次出现"新插入的行"（RC 存在，RR 大幅缓解但不完全解决）

1. RC 和 RR 的关键差异：

• ReadView 生成时机：RC 每次查询生成新 ReadView，RR 事务第一次查询时生成一次
• 锁机制：RC 只有行锁，无间隙锁；RR 有 next-key lock（行锁 + 间隙锁）防幻读
• 不可重复读：RC 存在（因为 ReadView 每次重生成），RR 不存在

1. MySQL 的 RR 是否解决幻读？

• 快照读（普通 SELECT）：不解决。因为快照读不受 next-key lock 保护，只能靠 ReadView 判断，但读到的仍然是事务开始时快照
• 当前读（SELECT FOR UPDATE / UPDATE / DELETE）：大部分解决。通过 next-key lock 锁住相关行和间隙
• 例外：WHERE 匹配范围 + 其他事务 INSERT 新行，再回当前事务查，可能看到"新行"（幻读）

1. 幻读的三种触发场景：

• 场景 1：RR 快照读，事务 A 内两次普通 SELECT，事务 B 期间 INSERT 新行 → 第二次 SELECT 看不到（不算幻读，是快照读特性）
• 场景 2：RR 快照读 + 当前读混用，事务 A 先 SELECT 后 SELECT FOR UPDATE，B 期间 INSERT → 当前读看到 B 插入的新行（幻读）
• 场景 3：RR 范围查询 WHERE id > ?，B 在间隙里 INSERT → 当前读看到新行（幻读，如果间隙锁没覆盖）

1. MySQL 默认 RR 的原因：

• Oracle 默认 RC，性能更好
• MySQL 默认 RR 是因为 InnoDB 的 MVCC 实现让 RR 也能保持较高并发
• 但生产环境很多团队会切到 RC，减少锁冲突、避免间隙锁死锁

1. Serializable 的实现：

• 所有 SELECT 隐式加 S 锁（共享锁）
• 写入加 X 锁（排他锁）
• 事务完全串行，并发度极低，很少生产使用

1. 实用参数：

• 会话级：SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
• 全局级：SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
• 事务级：START TRANSACTION ISOLATION LEVEL READ COMMITTED;
• 查看当前：SELECT @@transaction_isolation;

第二部分：考察方向与延伸递进

考察方向：

• 深度：能否讲清 ReadView 生成时机差异、锁机制差异
• 广度：能否区分脏读/不可重复读/幻读三种异常
• 应用：能否针对不同业务场景选择合适隔离级别

延伸递进面试题：

1. RC 下为什么没有间隙锁？会不会导致死锁？

• 解答要点：RC 只有行锁，锁范围小，死锁概率低。间隙锁是 RR 特有的，主要为了防幻读。

1. 为什么很多互联网团队生产环境选 RC 而不是 RR？

• 解答要点：RR 间隙锁死锁多、锁等待时间长；RC 锁粒度小并发好；只要业务不依赖 RR 的快照一致性，RC 足够。

1. MySQL 8.0 的 SELECT FOR UPDATE NOWAIT 在 RR 下会加什么锁？

• 解答要点：仍然加 next-key lock，行为不变，只是拿不到锁立即失败。

第三部分：面试者参考回答（口语化）

面试官您好，MySQL 的四种隔离级别我按从低到高讲。

READ UNCOMMITTED（读未提交）：能读到其他事务未提交的数据，最容易出问题但效率最高，实际几乎不用。

READ COMMITTED（读已提交）：只能读到其他事务提交后的数据，解决了脏读。Oracle 默认就是这个级别。RC 的特点是每个 SQL 查询都重新生成一个 ReadView，所以事务里如果其他事务提交了，我下一个查询就能看到。RC 只有行锁，没有间隙锁，死锁概率低，很多互联网公司生产用 RC。

REPEATABLE READ（可重复读）：同一事务内多次查询结果一致。MySQL 默认是 RR。核心机制是事务第一次查询时生成一个 ReadView，事务期间一直复用，所以看不到其他事务期间提交的改动。RR 的锁机制是 next-key lock，也就是行锁加间隙锁，主要用来防幻读。

关于幻读，很多人误以为 RR 完全解决了，其实不然。快照读的普通 SELECT 不受 next-key lock 保护，只能靠 ReadView 挡住一部分。真正会触发幻读的场景是快照读和当前读混用——事务 A 先普通 SELECT，然后 SELECT FOR UPDATE，如果事务 B 在中间 INSERT 了新行，A 的当前读就会看到 B 刚插入的数据。另外范围查询时如果间隙锁没覆盖到位，也可能看到新行。

SERIALIZABLE（串行化）：所有 SELECT 隐式加 S 锁，写入加 X 锁，事务完全串行执行。一致性最强，但并发度极低，生产很少用。

隔离级别切换可以用 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; 改会话，或者 START TRANSACTION ISOLATION LEVEL READ COMMITTED; 只在单个事务生效。

选择上我一般是这样考虑的：如果业务不需要可重复读的一致性，且想降低锁冲突，选 RC 就好；如果业务需要保证事务内的读取稳定，选 RR，但要接受间隙锁带来的死锁和锁等待风险；只有强一致场景（比如金融支付）才考虑 Serializable。

https://chat.deepseek.com/share/kvxo4aw3f312vm6wos