SQL数据库并发控制中锁和MVCC工作机制分别是什么

SQL数据库的并发控制是保障多用户同时操作数据时数据一致性的核心技术，其中锁机制和MVCC是最常用的两种实现方案。锁机制通过对数据资源加锁限制并发操作，避免脏读、不可重复读等问题，而MVCC则通过多版本管理实现读写互不阻塞，提升并发性能。

为什么需要并发控制

当多个事务同时访问数据库时，如果没有对应的控制机制，会出现多种数据一致性问题：

• 脏读：一个事务读取到另一个事务未提交的数据，若后者回滚，前者读取的数据就是无效的
• 不可重复读：同一个事务内多次读取同一数据，得到的结果不一致，因为其他事务修改了该数据并提交
• 幻读：同一个事务内多次查询同一范围的数据，后续查询出现了之前没有的新数据，因为其他事务插入了新记录

并发控制机制就是为了避免这些问题，在保障数据一致性的前提下尽可能提升数据库的并发处理能力。

锁机制的工作原理

锁机制的核心思想是当一个事务需要操作某部分数据时，先对该数据资源加锁，其他事务如果要操作同一资源，需要等待锁释放，以此限制并发冲突。

锁的常见分类

按照锁的粒度可以分为以下几类：

• 行锁：锁住表中的某一行记录，粒度最小，并发度最高，但是加锁开销最大
• 表锁：锁住整张表，粒度最大，并发度最低，但是加锁开销最小
• 页锁：锁住表中的一页数据，粒度介于行锁和表锁之间，并发度和开销也处于两者之间

按照锁的兼容性可以分为共享锁和排他锁：

锁的升级与死锁

当行锁的数量达到一定阈值时，数据库可能会将行锁升级为表锁，减少锁的管理开销，但是会降低并发度。另外如果多个事务互相等待对方释放锁，就会出现死锁，数据库一般会通过超时机制或者死锁检测来自动回滚其中一个事务解决死锁问题。

锁机制示例

以MySQL的InnoDB引擎为例，手动加锁的示例代码如下：

-- 开启事务
START TRANSACTION;
-- 对id为1的记录加排他锁
SELECT * FROM user WHERE id = 1 FOR UPDATE;
-- 执行更新操作
UPDATE user SET balance = balance - 100 WHERE id = 1;
-- 提交事务，释放锁
COMMIT;

MVCC的工作原理

MVCC即多版本并发控制，它的核心思路是为每行数据保存多个历史版本，读写操作不需要加锁，读操作读取对应版本的数据，写操作生成新的版本，以此实现读写互不阻塞，提升并发性能。

MVCC的核心组成

MVCC的实现依赖两个核心部分：

• 版本链：每行数据会有两个隐藏字段，trx_id（最后一次修改该记录的事务ID）和roll_pointer（回滚指针，指向该记录的上一个版本，所有版本通过指针串联成版本链）
• Read View：事务执行快照读时生成的读视图，里面记录了当前活跃的事务ID列表，用来判断版本链中的哪个版本对当前事务可见

版本可见性判断规则

Read View判断版本可见性的规则如下：

1. 如果版本的trx_id小于Read View中的最小活跃事务ID，说明该版本是在当前事务开启前就已经提交的，对当前事务可见
2. 如果版本的trx_id大于Read View中的最大活跃事务ID，说明该版本是在当前事务开启后生成的，对当前事务不可见
3. 如果版本的trx_id在Read View的活跃事务ID范围内，需要判断trx_id是否在活跃列表中，如果在则不可见，不在则可见

MVCC示例

假设user表有一条初始记录，id为1，name为张三，trx_id为100，现在有两个事务同时操作：

-- 事务A，trx_id为101，开启后执行快照读
START TRANSACTION;
-- 此时生成的Read View活跃事务列表为空，读取到trx_id为100的版本，结果为张三
SELECT name FROM user WHERE id = 1;

-- 事务B，trx_id为102，开启后执行更新
START TRANSACTION;
UPDATE user SET name = '李四' WHERE id = 1;
COMMIT;

-- 事务A再次执行快照读，Read View还是之前的，所以还是读取到trx_id为100的版本，结果还是张三
SELECT name FROM user WHERE id = 1;
COMMIT;

锁与MVCC的对比与适用场景

两种机制各有优劣，适用场景也不同：

实际数据库中往往会结合两种机制使用，比如InnoDB引擎的RR隔离级别下，快照读使用MVCC，当前读使用锁机制，兼顾一致性和性能。

SQL并发控制锁MVCC修改时间：2026-07-15 04:54:28