数据库事务隔离级别。

核心回答

事务隔离级别规定：并发事务的修改能在什么时候被其他事务看见，以及哪些并发异常不允许发生。 SQL 标准定义了四级：

• 读未提交（Read Uncommitted）：允许看到其他事务尚未提交的修改，可能出现脏读、不可重复读和幻读。
• 读已提交（Read Committed，RC）：不允许脏读，但同一事务前后两次读取之间，可能看到其他事务新提交的修改，仍允许不可重复读和幻读。
• 可重复读（Repeatable Read，RR）：不允许脏读和不可重复读；按标准的最低保证，仍允许幻读。数据库实现可以提供比标准更强的保证。
• 可串行化（Serializable）：并发事务的执行效果等价于按某种顺序逐个执行，防止上述异常及其他不可串行化的结果；实现通常需要更多冲突控制。

以 MySQL 8.4 InnoDB 为例，文档默认级别是 RR。RC 和 RR 的普通一致性读主要借助 MVCC：RC 每次读取建立新快照，RR 在同一事务中复用快照；锁定读和更新则使用当前记录及锁机制，不能把它们当成一直读取旧快照。

三种常见异常分别是什么？

脏读是读到了其他事务未提交的数据。例如 A 改了余额但还没提交，B 就读到新余额；如果 A 回滚，B 使用过的值从未成为有效的已提交结果。

不可重复读是同一事务重新读取原来读过的数据时，发现它被其他已提交事务修改。比如 B 先读余额 100，A 改成 80 并提交，B 再读变成 80。

幻读关注相同查询条件下的行集合。例如 B 两次查询“待处理订单”，期间 A 插入一条符合条件的订单并提交，B 第二次看到新的成员。关键是集合变化，不仅是行数增加，也不等于一条记录的某个字段变了。

标准中“允许某种异常”表示该级别没有承诺阻止它，不表示每次执行都会发生；也不能直接据此断言所有数据库的同名级别具有完全一样的行为。

InnoDB 的 RC 和 RR 怎样工作？

MVCC 通过记录版本、undo 历史和 Read View 判断哪些版本对当前读取可见，让普通查询可以读取合适的已提交版本，而不必总是等待并发写入结束。

• RC：每次一致性读获取新的快照。两个查询之间有其他事务提交，后一次可能看见它的修改。
• RR：通常在第一次一致性读时建立快照，后续一致性读复用。普通 BEGIN 并不意味着快照已经固定在执行 BEGIN 的时刻；也可以显式要求开始时建立一致性快照。

假设余额最初是 100，B 第一次普通查询后，A 将它改成 80 并提交；B 在同一事务中再次进行普通一致性读，RC 可以看到 80，RR 仍按原快照看到 100。这个例子讨论的是普通一致性读，且 B 没有自己修改这条记录。

RR 已经彻底解决所有并发问题了吗？

需要区分读取方式。RR 下，重复的普通一致性读不会因为其他事务后来插入数据，就在原快照里突然看到新行；它没有阻止其他事务插入，只是按快照控制可见性。

SELECT ... FOR UPDATE、FOR SHARE 等锁定读，以及更新、删除操作，会面向当前记录处理并发冲突。RR 中，对范围的锁定访问通常使用间隙锁或 next-key lock，阻止其他事务向受保护间隙插入；已有记录上的唯一索引等值查找可以只锁记录，不能说所有查询都会锁整个范围。RC 通常减少间隙锁，但写入仍会加锁，外键和唯一性检查等也有例外。

因此，先快照读、再锁定读，两次结果可能不同：它们本来就在使用不同的读取语义。事务自己的修改也可影响后续可见结果，不能把 RR 理解为“所有语句永远看到完全冻结的数据”。需要先查询再修改的业务，应明确锁定范围或使用条件更新、版本校验，并由数据库约束保护关键规则。

RR 也不等价于可串行化。例如两个事务分别读取同一组值，再根据旧状态修改不同记录，仍可能共同破坏跨记录约束。只核对脏读、不可重复读和幻读三项，不能证明所有业务执行结果都可串行化。

常见追问

可串行化是不是整库一次只运行一个事务？ 不是。它要求结果等价于某个串行顺序，不要求物理上完全串行。InnoDB 在非自动提交的事务中，会将普通查询隐式转为共享锁定读以加强冲突控制；仍可能发生等待或死锁，应用需要处理失败和重试。

隔离级别是不是越高越好？ 应看业务需要哪些保证、查询与更新方式、冲突范围和并发成本。RC 的读取更新鲜，却可能前后不一致；RR 提供稳定快照，范围锁也可能增加等待。默认级别和会话配置还可能被部署修改，应以实际配置和并发行为为准。

参考资料