MySQL事务并发问题与隔离级别详解：MVCC和行锁算法原理

事务并发导致的三大问题

在并发环境下，多个事务同时操作同一对象时，如果没有合理的隔离机制，会产生以下三种典型的数据不一致性问题：

第1步：理解脏读

概念：一个事务读取到了其他事务尚未提交的数据。如果该后续事务回滚，前一个事务读取到的数据即为无效数据。

第2步：理解不可重复读

概念：在同一个事务内，多次读取同一字段时，结果不一致。这通常是因为中间有其他事务对该记录进行了修改或删除。

第3步：理解幻读

概念：事务A按条件查询某个范围的数据，事务B在该范围内新增或删除了满足条件的记录。当事务A再次查询时，发现数据的行数发生了变化（即出现了“幻影行”）。

建议将“幻读”理解为“幻行”，即关注记录条数而非具体字段值的改变。

不可重复读与幻读的核心区别

• 前提一致：两者读取的都是已提交的数据。
• 不可重复读：核心在于“改”。同样的查询条件，第一次和第二次查到的具体数据内容不同。
• 幻读：核心在于“增/删”。同样的查询条件，第一次和第二次查到的记录行数不同。

事务的四个隔离级别

为了解决上述并发问题，SQL标准定义了四种事务隔离级别。需要注意的是，SQL是独立于厂商的标准语言，各大数据库（如PostgreSQL、Oracle等）均支持这些标准。

查看与设置隔离级别

可以通过以下命令查看当前会话或全局的隔离级别：

SHOW GLOBAL VARIABLES LIKE '%isolation%';
SHOW SESSION VARIABLES LIKE '%isolation%';
SET SESSION autocommit = 0; // 关闭自动提交以手动开启事务测试

官方定义的四种设置语法如下：

-- 1. 读未提交 (Read Uncommitted)
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- 2. 读已提交 (Read Committed)
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 3. 可重复读 (Repeatable Read) - MySQL默认
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- 4. 串行化 (Serializable)
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

一般原则是：隔离级别越高，并发性能越低，安全性越高。RU级别实际极少使用；Serializable级别性能最低，几乎退化到串行执行。开发中最常用的是 RC 和 RR。

InnoDB默认的RR级别与机制基础

InnoDB引擎默认的隔离级别是 REPEATABLE READ（可重复读）。为了实现非串行的并发控制而不牺牲过多性能，InnoDB主要依赖两大核心机制：MVCC（多版本并发控制）来处理快照读，以及基于索引的行锁（Locking）来处理当前读。

MVCC（多版本并发控制）实现原理

MVCC的核心在于让事务能够看到不同版本的数据，从而在不加锁的情况下保证一致性。它主要由两个部分组成：Undo Log版本链和Read View（读视图）。

1. Undo Log版本链

对于每一行记录，InnoDB存储了两个隐藏字段：

• row_trx_id：标识更新该行记录的事务ID。
• roll_pointer：回滚指针，指向该记录的上一个版本（位于Undo Log中）。

当一个记录被多次修改时，旧版本会被存储在Undo Log中，并通过 roll_pointer 连接成一条版本链。

2. Read View（读视图）与可见性判断规则

事务在进行快照读时，会生成一个 Read View，包含四个关键属性：

• create_trx_id：当前正在读取数据的事务ID。
• m_idx：当前活跃事务ID列表（数组）。
• min_trx_id：活跃事务中的最小ID。
• max_trx_id：系统当前最大的事务ID + 1。

判断某条记录版本是否对当前事务可见的规则（永远成立）：

• 若 row_trx_id < min_trx_id：说明版本产生于当前事务开启之前且已提交，可见。
• 若 row_trx_id >= max_trx_id：说明版本产生于当前事务之后，不可见。
• 若 min_trx_id <= row_trx_id < max_trx_id：
  • 若在 m_idx 中（且不等于当前事务ID），表示是该事务启动时尚未提交的修改，不可见。
  • 若不在 m_idx 中，表示是已提交的其他事务修改，可见。

RC与RR级别下MVCC的差异

可重复读 (RR) 的实现

在 RR 级别下，Read View 仅在事务执行的第一个 SELECT 语句时创建一次，并在整个事务期间保持不变。

这意味着，即使其他事务提交了新的修改，当前事务依然能看到其创建时的快照数据，从而解决了不可重复读和脏读。

例如：事务A第一次查询生成Read View，此时事务B还在运行。当A第二次查询时，虽然B已经提交，但因为A使用的依然是旧的Read View，所以看不到B的提交结果。

读已提交 (RC) 的实现

在 RC 级别下，**每次执行 SELECT 语句都会重新创建一个最新的 Read View**。

这意味着只要其他事务提交了更新，当前事务就能在当前查询中看到最新的结果。因此，RC解决了脏读，但无法解决不可重复读。

事务A第一次查询生成Read View V1（包含活跃事务B）。B提交后，事务A第二次查询生成Read View V2（B不在活跃列表中），根据规则V2认为B的修改可见，导致两次查询结果不一致。

锁机制（LBCC）解决当前读问题

MVCC主要适用于 SELECT（快照读）场景。当涉及到 UPDATE、DELETE 或加了锁的 SELECT ... FOR UPDATE 时，InnoDB必须加锁，以防止并发写入冲突。这就是基于锁的并发控制（Lock-Based Concurrent Control, LBCC）。

共享锁与排它锁

• 共享锁（S锁/读锁）：允许读，阻塞写。用于 SELECT ... LOCK IN SHARE MODE。
• 排它锁（X锁/写锁）：允许写，阻塞读和写。用于 UPDATE、DELETE 和 SELECT ... FOR UPDATE。
• 意向锁：InnoDB维护的表级锁（IS/IX），用于加速判断表级加锁是否会发生冲突。

行锁的原理：锁住的是索引

InnoDB的行锁是通过索引实现的。如果查询没有使用索引，则会退化为全表扫描，进而锁住所有扫描过的行（实际上表现为锁表）。

此外，即使是通过辅助索引（二级索引）锁定数据，也会沿着索引叶子节点的主键值去锁定主键索引，因为它们锁定的是物理上的同一行数据。

为什么需要辅助索引也锁主键？

因为InnoDB的数据页面是按主键聚簇存储的。无论通过哪个索引访问，最终都要定位到这一行物理记录上。

锁的三种算法：Record、Gap、Next-Key

为了避免并发插入产生的“幻读”问题，InnoDB在RR级别使用了复杂的锁区间算法。我们需要先定义三个区间概念：

• Record（记录）：存在于B+树叶子节点的真实数据行。
• Gap（间隙）：左右都为开区间的记录间隔区域。
• Next-Key（临键）：左开右闭区间，由Gap加上其左侧的记录组成。

1. Record Lock（记录锁）

只锁住索引记录本身。仅在对唯一性索引（主键或唯一索引）进行精确匹配（等值查询）时使用。

SELECT * FROM user WHERE id = 1 FOR UPDATE;

2. Gap Lock（间隙锁）

锁定索引之间的间隙，不锁定记录本身。主要用于阻止其他事务向该间隙插入数据，从而防止幻读。相同的Gap Lock之间不冲突（允许并发插入不同的间隙）。

SELECT * FROM user WHERE id BETWEEN 1 AND 4 FOR UPDATE;

3. Next-Key Lock（临键锁/临行锁）

这是InnoDB在RR级别下的默认行锁算法。它是 Gap Lock + Record Lock 的组合（左开右闭区间）。

作用：既锁住了具体的记录，也锁住了后面的间隙。这样可以确保其他事务无法向该记录所在的间隙中插入新数据，彻底解决了范围查询时的幻读问题。

总结

InnoDB通过在RR级别下采用 Next-Key Lock 算法，成功解决了范围查询带来的幻读问题；而在RC级别下由于不使用Gap Lock，无法避免插入型幻读。

各隔离级别特性小结：

• RUN: 不加任何锁，性能最高，数据安全性极低。
• SERIALIZABLE: 强制串行化，通过加共享锁阻塞其他事务，安全性最高，性能最差。
• RR (Repeatable Read): SELECT 用MVCC（快照读），UPDATE/DELETE/LOCKED SELECT 用 Next-Key Lock。既能保证一致性又兼顾并发效率，是MySQL默认首选。
• RC (Read Committed): SELECT 每次建立新Read View；更新时只用 Record Lock。并发性能好，但可能出现不可重复读。

在实际开发中，除非业务场景明确要求强一致性或为了极高的并发写入能力而接受不可重复读，否则应优先使用默认的RR级别。同时需注意，在使用行锁时务必确保WHERE条件命中索引，否则可能导致锁粒度升级为表锁，引发严重性能瓶颈甚至死锁。

以上就是MySQL事务隔离级别、MVCC以及行锁算法实现的详细内容，更多关于数据库高性能优化设计的资料请关注本站其它相关文章！