当前位置：首页 > news >正文

MySQL 中 MVCC 和锁的关系与配合

news 2026/5/12 10:41:57

MySQL 中 MVCC 和锁的关系与配合

MySQL 的 InnoDB 存储引擎通过MVCC（多版本并发控制）和锁机制来处理并发事务。这两者并非各自为政，而是紧密协作、分工明确：

MVCC主要负责读操作（尤其是普通查询），通过提供数据的历史快照，实现“读写不冲突”，从而极大提升并发性能。
锁机制则负责写操作以及需要强一致性的读操作，通过对数据加锁来保证修改安全，防止数据混乱。

MVCC 与锁机制对比

特性维度	MVCC (多版本并发控制)	锁机制 (Locking)
核心思想	保存数据的多个历史版本，让读操作看到“过去”的快照。	对数据对象加锁，使并发操作“排队”执行。
主要应用	快照读：即普通的`SELECT`语句，不加锁，效率最高。	当前读：`SELECT ... FOR UPDATE`、`SELECT ... LOCK IN SHARE MODE`、`UPDATE`、`DELETE`、`INSERT`。
解决的问题	主要解决读-写冲突，让读不阻塞写，写也不阻塞读。	主要解决写-写冲突，确保并发修改的安全性和隔离性。
依赖的组件	`Undo Log`（构建历史版本链）、`Read View`（判断版本可见性）。	记录锁（Record Lock）、间隙锁（Gap Lock）、临键锁（Next-Key Lock）等。

分工配合详解

1. 快照读：MVCC 独挑大梁

当你执行普通查询（如SELECT * FROM user WHERE id = 1）时，MVCC 全权负责。
InnoDB 会根据当前事务隔离级别生成一个Read View，然后利用Undo Log中的版本链，快速返回一个符合隔离级别要求的数据快照。整个过程不加任何锁，即使其他事务正在修改同一行，查询也不会被阻塞，实现了“读写并发”。

2. 当前读：锁机制接管控制

当你执行修改语句或加锁查询（如UPDATE、DELETE、SELECT ... FOR UPDATE）时，锁机制开始发挥作用。

语句首先执行“当前读”，找到数据的最新版本，并立即为其加上排他锁（X锁）（或根据语句类型加共享锁）。
根据操作类型和隔离级别，还可能添加间隙锁或临键锁，防止幻读。
其他事务若想加锁访问该数据，必须等待当前事务释放锁。

3. 同一事务中的协同

在一个较长的事务中，MVCC 和锁机制会根据 SQL 语句动态切换。
例如：事务开始时的普通查询（快照读）→ 之后的UPDATE（切换为当前读并加锁）→ 再次普通查询（再次使用 MVCC，但可能受到之前更新的影响）。整个过程由 InnoDB 自动管理，对用户透明。

完整配合流程示例

以下用两个事务（A 和 B）几乎同时操作同一行数据的过程，展示 MVCC 与锁的协作：

事务 A 启动，执行普通查询
SELECT * FROM product WHERE id = 1;
- MVCC 生效，创建Read View，返回数据快照。
- 未加任何锁，读写互不阻塞。
事务 B 启动，执行修改
UPDATE product SET stock = stock - 10 WHERE id = 1;
- 步骤一（锁定读）：先执行“当前读”，找到id=1的最新记录，并加上排他锁（X锁）。
- 步骤二（执行修改）：修改数据，并将旧版本写入Undo Log，形成新版本链。
- 步骤三（持有锁）：在事务 B 提交前一直持有排他锁。
其他事务的“当前读”被阻塞
若事务 A 或其他事务尝试执行SELECT ... FOR UPDATE或另一个UPDATE操作同一行，锁机制会让它们进入等待状态，直到事务 B 提交释放锁。
快照读不受影响
若事务 A 再次执行普通SELECT * FROM product WHERE id = 1;
- 由于是快照读，它会根据自己一开始生成的Read View从Undo Log版本链中读取历史版本，不会被排他锁阻塞，立即返回结果。
事务结束
事务 B 提交，释放排他锁。其他被阻塞的“当前读”操作获取锁，并看到事务 B 修改后的最新数据。