mysql幻读问题

问题:

  1. 什么样的情况叫做幻读?
  2. Mysql 可重复读隔离级别下,到底能不能阻止幻读?
  3. 什么是当前读,什么是快照读?

幻读的定义:

事务A 按照一定条件进行数据读取, 期间事务B 插入了相同搜索条件的新数据,事务A再次按照原先条件进行读取时,发现了事务B 新插入的数据 称为幻读

如果事务A 按一定条件搜索, 期间事务

B 删除了符合条件的某一条数据,导致事务A 再次读取时数据少了一条。这种情况归为 不可重复读 

准备工作:

Mysql 隔离级别为 可重复读;

CREATE TABLE `author` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8;

INSERT into author VALUES (1,'g1',20),(5,'g5',20),(15,'g15',30),(20,'g20',30);

查找年龄为20岁的作者,并把姓名改成G0

来分析下情形:

  • T1时刻 读取年龄为20的数据, Session1拿到了2条记录。
  • T2时刻
  • 进程Session2插入了一条新的记录,年龄也为20
  • T3时刻,Session1再次读取年龄为20的数据,发现还是2条数据,貌似 Session2新插入的数据并未影响到Session1的事务读取。
对于T1 -- T3 时刻的情形,从结果来看,在可重复度读隔离级别下似乎解决了幻读的问题。
  • T4时刻,Session1 修改年龄为20的数据, 发现影响行数为3条。 为什么T3时候只能查到2条数据,但现在修改确修改了3条数据?
  • T5时刻,Session1 再次读取年龄为20的数据,发现结果变成了3条,我们知道被修改的第三条就是Session2在T2时刻新增的一条。
T4,T5 的结果来看,Session1 读到了 Session2 新插入的数据。产生了幻读现象

到底可重复读隔离级别下,解决了幻读问题没有?

了解过MVCC的同学,肯定知道或听说过当前读,和快照读。(不知道的同学,可以查找相关资料了解下,当然后续我也会有文章专门介绍MVCC)。首先要知道的是MVCC 就InnoDB 秒级建立数据快照的能力。 快照读就是读取数据的时候会根据一定规则读取事务可见版本的数据。 而当前读就是读取最新版本的数据。什么情况下使用的是快照读:(快照读,不会加锁)

一般的 select * from .... where ... 语句都是快照读

什么情况下使用的是当前读:(当前读,会在搜索的时候加锁)

select * from .... where ... for update select * from .... where ... lock in share mode update .... set .. where ... delete from. . where ..

如果事务中都使用快照读,那么就不会产生幻读现象,但是快照读和当前读混用就会产生幻读。

如果都是使用当前读,能不能解决幻读问题?

先让我们数据恢复到初始状态

TRUNCATE TABLE author;
INSERT into author VALUES (1,'g1',20),(5,'g5',20),(15,'g15',30),(20,'g20',30);

可以看到Session 2 被阻塞了。需要等到Session1 提交事务后才能完成。当我们在事务中每次读取都使用当前读,也就是人工把InnoDB变成了串行化。一定程度上降低了并发性,但是也同样避免了幻读的情况。

当前读为什么会阻塞新数据的插入,主要是间隙锁的加锁机制。(Mysql 的锁也是个大问题,后续有专门的章节介绍)

总结:

  • 希望通过这篇文章,了解幻读的定义。读到了其他事务新插入的数据,这种现象较幻读。
  • 当前读和快照读的区别,以及了解什么时候是快照读,什么时候是当前读
  • 可重复读隔离级别下,一个事务中只使用当前读,或者只使用快照读都能避免幻读。
  • mysql如何实现避免幻读

    • 在快照读读情况下,mysql通过mvcc来避免幻读。
    • 在当前读读情况下,mysql通过间隙锁来避免幻读

### MySQL的概念及解决方案 #### 的定义 是一种在并发环境下可能出现的数据一致性问题。当某个事务多次执行同一查询时,由于其他事务插入或删除了数据,导致每次查询的结果集不同,这种现象被称为[^1]。 #### 的影响 可能会影响数据库的可靠性和数据的一致性,尤其是在需要严格控制数据状态的应用场景中。因此,在设计数据库应用时,需特别关注如何避免的发生。 #### 事务隔离级别的作用 MySQL 提供了四种主要的事务隔离级别,分别是 `READ UNCOMMITTED`、`READ COMMITTED`、`REPEATABLE READ` 和 `SERIALIZABLE`。这些隔离级别通过不同的方式控制事务间的可见性和交互行为,从而减少诸如问题的发生[^2]。 | 隔离级别 | 脏 | 不可重复 | | |--------------------|------------|----------------|--------------| | **READ UNCOMMITTED** | 可能发生 | 可能发生 | 可能发生 | | **READ COMMITTED** | 解决 | 可能发生 | 可能发生 | | **REPEATABLE READ** | 解决 | 解决 | 可能发生 | | **SERIALIZABLE** | 解决 | 解决 | 解决 | #### 各隔离级别下的处理能力 - 在 `READ UNCOMMITTED` 和 `READ COMMITTED` 下,无法被完全解决。 - 在 `REPEATABLE READ` 下,默认情况下 MVCC(多版本并发控制)机制能够防止大多数类型的不一致取,但对于新插入的记录仍可能存在风险。 - 在最高隔离级别 `SERIALIZABLE` 下,所有事务都以串行的方式运行,彻底杜绝了的可能性,但会显著降低系统的性能和吞吐量[^4]。 #### 解决的具体方法 针对问题,有多种可行的解决方案: 1. **提升隔离级别至 SERIALIZABLE** 将事务隔离级别设置为 `SERIALIZABLE` 是一种简单而有效的方法,因为在这种模式下所有的操作都会按照严格的顺序依次执行,从根本上消除了的风险。然而,这种方法会对系统性能带来较大的负面影响,适用于对一致性要求极高且性能压力较小的场景[^2]。 2. **使用 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE** 如果应用程序允许显式的锁管理,则可以在查询语句后面附加 `FOR UPDATE` 或者 `LOCK IN SHARE MODE` 子句。这将强制锁定所涉及的行或者范围,阻止其他事务在此期间修改或新增相关数据,进而达到预防的效果[^3]。 ```sql -- 使用 FOR UPDATE 锁定目标行 SELECT * FROM t_stu WHERE id = 5 FOR UPDATE; -- 使用 LOCK IN SHARE MODE 实现共享锁 SELECT * FROM t_stu WHERE id = 5 LOCK IN SHARE MODE; ``` 3. **调整业务逻辑** 对于某些特定场景,也可以通过对业务流程的设计优化来间接规避问题。例如,先获取当前最新的快照作为基础再做进一步的操作,而不是依赖实时动态变化的数据集合。 --- ### 总结 综上所述,问题数据库领域常见的挑战之一,但在 MySQL 数据库中有成熟的应对策略可供选择。依据实际需求权衡性能与一致性之间的关系,合理选用适合的事务隔离级别以及辅助技术手段即可妥善解决问题
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值