最近在准备面试，正把平时积累的笔记、项目中遇到的问题与解决方案、对核心原理的理解，以及高频业务场景的应对策略系统梳理一遍，既能加深记忆，也能让知识体系更扎实，供大家参考，欢迎讨论。

在数据库并发操作场景中，事务隔离级别是保障数据一致性的核心机制，不同隔离级别对应不同的并发控制策略，而 MVCC（多版本并发控制）则是实现部分隔离级别的关键技术。

一、数据库事务隔离级别概述

事务隔离级别定义了多个并发事务之间的相互影响程度，从低到高分为四个级别，不同级别在数据一致性和系统性能之间呈现不同的平衡关系。

1.1 读未提交（Read Uncommitted）

• 定义：最低的隔离级别，允许当前事务读取其他事务尚未提交的数据变更。

• 核心问题：无法避免脏读、不可重复读和幻读。

• 脏读：读取到其他事务未提交的“临时数据”，若后续事务回滚，当前读取的数据将变为无效。

• 适用场景：对数据一致性要求极低，仅追求极致性能的场景（如临时统计查询，无需精确结果），实际业务中极少使用。业务场景基本都不用。

1.2 读已提交（Read Committed, RC）

• 定义：允许当前事务读取其他事务已提交的数据变更，是许多数据库的默认隔离级别之一（如 Oracle）。

• 核心能力：可阻止脏读，但仍可能出现不可重复读和幻读。

◦ 不可重复读：同一事务内，对同一字段多次读取，结果因其他事务提交的更新操作而不同。◦ 幻读：同一事务内，执行相同的查询语句，结果因其他事务提交的插入/删除操作而新增或减少数据行。

• 实现依赖：基于 MVCC 机制实现，通过读取数据的“已提交版本”保障数据有效性。

1.3 可重复读（Repeatable Read, RR）

• 定义：MySQL InnoDB 引擎的默认隔离级别，确保同一事务内，对同一字段的多次读取结果一致（除非数据由当前事务自身修改）。

• 核心能力：可阻止脏读和不可重复读，但仍可能出现幻读（需通过额外机制解决）。

• 幻读解决方案：

◦ 升级隔离级别至串行化：所有事务顺序执行，完全避免并发干扰，但会导致性能大幅下降，仅适用于数据一致性要求极高且并发量低的场景。◦ MVCC 解决快照读幻读：针对简单 SELECT（快照读），通过读取数据的历史版本（非最新版本），确保同一事务内查询结果一致。MySQL使用的这个来解决幻读，相对锁解决幻读而言，性能较高。◦ GapLock + Next-KeyLock 解决当前读幻读：针对 SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE 等当前读操作，通过间隙锁（GapLock）和 next-key 锁，锁定查询范围，防止其他事务插入/删除数据，避免幻读。

1.4 串行化（Serializable）

• 定义：最高的隔离级别，强制所有事务按顺序逐个执行，完全禁止并发操作。互联网项目基本没用这个的，项目上线有点并发就会非常卡顿了。

• 核心能力：完全符合 ACID 的隔离要求，可阻止脏读、不可重复读和幻读，数据一致性最强。

• 缺点：极大限制并发性能，仅适用于数据安全性优先于性能的极端场景（如金融核心交易的关键步骤）。在这里插入图片描述

二、MVCC（多版本并发控制）机制

MVCC 是一种高效的并发控制技术，主要用于实现 “读已提交（RC）” 和 “可重复读（RR）” 隔离级别，通过维护数据的多个版本，实现 “读 - 写”“写 - 读” 并发执行，在保障数据一致性的同时提升系统性能。

2.1 MVCC 的核心原理

MVCC 的核心是为每行数据维护多个历史版本，事务读取时根据自身版本号选择可见的数据版本，避免直接加锁导致的并发瓶颈。其关键机制包括：

事务版本号
◦ 系统会为每个新启动的事务分配一个唯一的递增版本号（transaction_id），事务开始时的版本号即为该事务的标识。

◦ 数据行的版本号与事务版本号关联，确保事务只能读取符合可见性规则的数据。

隐藏列与版本链
◦ InnoDB 引擎的聚簇索引记录中，默认包含两个隐藏列，用于构建数据的版本链：

 ▪ trx_id：存储每次修改该数据行的事务 ID，记录数据的“修改者”。▪ roll_pointer：存储一个指针，指向该数据行的上一个历史版本（存储在 Undo 日志中），通过该指针可串联所有历史版本，形成“版本链”。

◦ 注意：插入操作的 Undo 日志无 roll_pointer，因为插入的数据无历史版本。

Undo 日志的作用
◦ Undo 日志用于保存数据的历史版本，当事务需要读取历史数据时，通过 roll_pointer 从 Undo 日志中获取对应版本。

◦ 事务提交后，Undo 日志不会立即删除，而是根据垃圾回收机制（Purge）在合适时机清理，确保其他事务仍能访问所需的历史版本。

2.2 MVCC 的适用范围与限制

• 适用隔离级别：仅支持 “读已提交（RC）” 和 “可重复读（RR）”，不支持 “读未提交”（需读取未提交数据，与 MVCC 的“版本可见性规则”冲突）和 “串行化”（强制顺序执行，无需 MVCC）。

• 适用读操作类型：

◦ 快照读：简单 SELECT 语句（无 FOR UPDATE、LOCK IN SHARE MODE），通过 MVCC 读取历史版本，无需加锁，并发性能高。◦ 当前读：DELETE、UPDATE、INSERT 及 SELECT ... FOR UPDATE 等操作，需读取数据最新版本，并加锁防止并发修改，不依赖 MVCC 的版本链，而是通过锁机制保障一致性。

2.3 MVCC 与乐观锁的关联

MySQL 的 MVCC 本质是乐观锁的一种实现方式：

• 每行数据的版本号（通过 trx_id 和版本链间接体现）作为乐观锁的“版本标识”。

• 事务更新数据时，会检查当前数据的版本号是否与预期一致（类似 “WHERE version = V” 的逻辑），若一致则更新并生成新版本，若不一致则重试或失败，避免并发冲突。