MySQL如何解决幻读与不可重复读

编程达人挑战赛·第1期 10w+人浏览 376人参与

1. MySQL中的3种锁算法

首先了解下MySQL中的3种锁算法:

  • Record lock:记录锁(行锁),单条索引记录上加锁,锁住的永远是索引,而非记录本身。

  • Gap lock:间隙锁,在索引记录之间的间隙中加锁,或者是在某一条索引记录之前或者之后加锁,并不包括该索引记录本身。

  • Next-key lock:临键锁,Record lock 和 Gap lock 的结合,即除了锁住记录本身,也锁住索引之间的间隙。

下面来详细介绍下这三种锁:

1.1 记录锁Record Lock

顾名思义,记录锁就是为某行记录加锁,它封锁该行的索引记录:

-- id 列为主键列或唯一索引列
SELECT * FROM 表名称 WHERE id = 1 FOR UPDATE;

这时候 id 为 1 的记录行会被锁住。

需要注意的是:

  • id 列必须为唯一索引列或主键列,否则上述语句加的锁就会变成临键锁。(行锁在 InnoDB 中是基于索引实现的,所以一旦某个加锁操作没有使用索引,那么该锁就会退化为表锁)

  • 同时查询语句必须为精准匹配=,不能为 >、<、like等,否则也会退化成临键锁。

在通过主键索引唯一索引对数据行进行UPDATE操作时,也会对该行数据加记录锁:

-- id 列为主键列或唯一索引列
UPDATE SET age = 50 WHERE id = 1;

1.2 间隙锁Gap Locks

间隙锁基于非唯一索引,它锁定一段范围内的索引记录。间隙锁基于下面将会提到的Next-Key Locking 算法,请务必牢记:使用间隙锁锁住的是一个区间,而不仅仅是这个区间中的每一条数据。

SELECT * FROM 表名称 WHERE id BETWEN 1 AND 10 FOR UPDATE;
  • 即所有在(1,10)区间内的记录行都会被锁住,所有id 为 2、3、4、5、6、7、8、9 的数据行的插入会被阻塞,但是 1 和 10 两条记录行并不会被锁住。

  • 除了手动加锁外,在执行完某些 SQL 后,InnoDB 也会自动加间隙锁,这个我们在下面会提到。

1.3 临键锁Next-Key Locks

Next-Key 可以理解为一种特殊的间隙锁,也可以理解为一种特殊的算法。通过临建锁可以解决幻读的问题。 每个数据行上的非唯一索引列上都会存在一把临键锁,当某个事务持有该数据行的临键锁时,会锁住一段左开右闭区间的数据。需要强调的一点是,InnoDB 中行级锁是基于索引实现的,临键锁只与非唯一索引列有关,在唯一索引列(包括主键列)上不存在临键锁。

假设有如下表:

引擎:InnoDB,隔离级别:Repeatable-Read:table(id PK, age KEY, name)

idagename
110Lee
324Soraka
532Zed
745Talon

该表中age列潜在的临键锁有:

(-, 10],
(10, 24],
(24, 32],
(32, 45],
(45, +],

在事务 A 中执行如下命令:

-- 根据非唯一索引列 UPDATE 某条记录
UPDATE table SET name = Vladimir WHERE age = 24;
-- 或根据非唯一索引列 锁住某条记录
SELECT * FROM table WHERE age = 24 FOR UPDATE;

不管执行了上述 SQL 中的哪一句,之后如果在事务 B 中执行以下命令,则该命令会被阻塞:

INSERT INTO table VALUES(100, 26, 'Ezreal');

很明显,事务 A 在对 age 为 24 的列进行 UPDATE 操作的同时,也获取了 (24, 32] 这个区间内的临键锁。

不仅如此,在执行以下 SQL 时,也会陷入阻塞等待:

INSERT INTO table VALUES(100, 30, 'Ezreal');

那最终我们就可以得知,在根据非唯一索引对记录行进行 UPDATE \ FOR UPDATE \ LOCK IN SHARE MODE 操作时,InnoDB 会获取该记录行的临键锁 ,并同时获取该记录行下一个区间的间隙锁

即事务 A在执行了上述的 SQL 后,最终被锁住的记录区间为 (10, 32)。

1.4 小结

  • InnoDB 中的行锁的实现依赖于索引,一旦某个加锁操作没有使用到索引,那么该锁就会退化为表锁。
  • 记录锁存在于包括主键索引在内的唯一索引中,锁定单条索引记录。
  • 间隙锁存在于非唯一索引中,锁定开区间范围内的一段间隔,它是基于临键锁实现的。在索引记录之间的间隙中加锁,或者是在某一条索引记录之前或者之后加锁,并不包括该索引记录本身。
  • 临键锁存在于非唯一索引中,该类型的每条记录的索引上都存在这种锁,它是一种特殊的间隙锁,锁定一段左开右闭的索引区间。即,除了锁住记录本身,也锁住索引之间的间隙。
    注意:

InnoDB 行锁是通过索引上的索引项来实现的。意味者:只有通过索引条件检索数据,InnoDB 才会使用行级锁,否则,InnoDB将使用表锁!

  • 对于主键索引:直接锁住锁住主键索引即可。
  • 对于普通索引:先锁住普通索引,接着锁住主键索引,这是因为一张表的索引可能存在多个,通过主键索引才能确保锁是唯一的,不然如果同时有2个事务对同1条数据的不同索引分别加锁,那就可能存在2个事务同时操作一条数据了。

扩展:MySQL 如何实现悲观锁和乐观锁?

  • 乐观锁:更新时带上版本号(cas更新)
  • 悲观锁:使用共享锁和排它锁,select…lock in share mode,select…for update。

2. MySQL如何解决不可重复读

MySQL中,默认使用的事务隔离界别是可重复读,为了解决不可重复读问题,InnoDB采用了MVCC(多版本并发控制)【基于乐观锁】来解决!
MVCC(多版本并发控制)是利用在每条数据后面加了隐藏的两列(创建版本号和删除版本号),每个事务在开始的时候都会有一个递增的当前事务版本号!
例如:

-- MVCC新增
begin; -- 假设获取的 当前事务版本号=1
insert into user (id,name,age) values (1,"张三",10); -- 新增,当前事务版本号是1
insert into user (id,name,age) values (2,"李四",12); -- 新增,当前事务版本号是1
commit; -- 提交事务
idnameagecreate_versiondelete_version
1张三101NULL
2李四121NULL
-- 上表可以看到,插入的过程中会把当前事务版本号记录到列 create_version 中去!
-- MVCC删除:删除操作是直接将行数据的删除版本号更新为当前事务的版本号
begin--假设获取的 当前事务版本号=3
delete from user where id = 2;
commit; -- 提交事务
idnameagecreate_versiondelete_version
1张三101NULL
2李四1213
-- MVCC更新操作:采用 delete + add 的方式来实现,首先将当前数据标志为删除,然后再新增一条新的数据
begin;-- 假设获取的 当前事务版本号=10
update user set age = 11 where id = 1; -- 更新,当前事务版本号是10
commit; -- 提交事务
idnameagecreate_versiondelete_version
1张三101NULL
2李四1213
1张三1110NULL
-- MVCC查询操作:
begin;-- 假设拿到的系统事务ID为 12
select * from user where id = 1;
commit; -- 提交事务

查询操作为了避免查询到旧数据或已经被其他事务更改过的数据,需要满足如下条件:

1、查询时当前事务的版本号需要大于或等于创建版本号create_version

2、查询时当前事务的版本号需要小于删除的版本号delete_version,或者当前删除版本号delete_version=NULL

即:(create_version <= current_version < delete_version) || (create_version <= current_version && delete_version-=NULL) ,这样就可以避免查询到其他事务修改的数据,同一个事务中,实现了可重复读!

执行结果应该是:

id name age create_version delete_version
1 张三 11 10 NULL

3. MySQL如何解决幻读

3.1 MySQL采用的MVCC可以解决幻读吗?

幻读:在一个事务中使用相同的 SQL 两次读取,第二次读取到了其他事务新插入的行,则称为发生了幻读。

例如:

  • 1)事务1第一次查询:select * from user where id < 10 时查到了 id = 1 的数据

  • 2)事务2插入了 id = 2 的数据

  • 3)事务1使用同样的语句第二次查询时,查到了 id = 1、id = 2 的数据,出现了幻读。

谈到幻读,首先我们要引入“当前读”和“快照读”的概念,通过名字就可以理解:

  • 快照读:生成一个事务快照(ReadView),之后都从这个快照获取数据。普通 select 语句就是快照读。
  • 当前读:读取数据的最新版本。常见的 update/insert/delete、还有 select … for update、select … lock in share mode 都是当前读。

对于快照读,MVCC 因为因为从 ReadView 读取,所以必然不会看到新插入的行,所以天然就解决了幻读的问题。
而对于当前读的幻读,MVCC 是无法解决的。需要使用 Gap Lock 或 Next-Key Lock(Gap Lock + Record Lock)来解决。

其实原理也很简单,用上面的例子稍微修改下以触发当前读:select * from user where id < 10 for update,当使用了 Gap Lock 时,Gap 锁会锁住 id < 10 的整个范围,因此其他事务无法插入 id < 10 的数据,从而防止了幻读。

3.2 有人说 RR 解决了幻读是什么情况?

SQL 标准中规定的 RR 并不能消除幻读,但是 MySQL 的 RR 可以,靠的就是 Gap 锁。在 RR 级别下,Gap 锁是默认开启的,而在 RC 级别下,Gap 锁是关闭的。

### MySQL不可重复的区别及产生原因 #### 不可重复 (Non-Repeatable Read) 不可重复是指在一个事务中多次查询同一数据时,返回的结果不一致的现象。这种情况通常发生在另一个事务对该数据进行了修改并提交之后。具体来说,在 **READ COMMITTED** 隔离级别下,当一个事务第一次取某条记录后,如果其他事务对该记录进行了更新并提交,则当前事务再次取同一条记录时可能会得到不同的结果。 这种现象的根本原因是数据库允许在不同时间点上查看到最新的已提交版本的数据[^1]。为了防止不可重复的发生,可以通过提升隔离级别至 **REPEATABLE READ** 或更高来解决。在这种隔离级别下,MySQL 使用多版本并发控制(MVCC),确保同一个事务内的每次查询都能看到相同的一致性视图。 #### (Phantom Read) 则是指在一个事务中执行两次相同的范围查询时,第二次查询的结果集中出现了新的记录或缺少某些记录的现象。这通常是由于其他事务在此期间向目标范围内插入了新数据所致。例如,假设某个事务基于特定条件检索了一组记录,而在其完成之前,另一事务插入满足这些条件的新行,则原始事务重新执行此查询时将观察到额外的“幽灵”行。 针对问题,MySQL解决方案是在更高的隔离级别如 **SERIALIZABLE** 下采用表级锁定策略;或者更常见的是在 **REPEATABLE READ** 层面上利用间隙锁(Gap Locks)技术来封锁可能被插入的位置,从而避免此类情况发生[^2]。 #### 总结对比 | 特性 | 不可重复 | | |-------------------|----------------------------------|------------------------------------| | 定义 | 同一事务内对单条记录前后取结果不一致 | 同一事务内对某一范围数据前后取集合发生变化 | | 发生场景 | 数据被其他事务更新 | 新增/删除操作由其他事务引起 | | 解决方法 | 提升至 REPEATABLE READ 及以上隔离级别 | SERIALIZABLE 或者通过 GAP LOCK 实现 | ```sql -- 示例代码展示如何设置不同的隔离级别 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; START TRANSACTION; SELECT * FROM students WHERE id = 1; -- 初次取 UPDATE students SET major='CS' WHERE id=1; -- 假设这是来自另一个事务的操作 COMMIT; SELECT * FROM students WHERE id = 1; -- 再次取可能出现不可重复 ``` 问题
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值