透彻解读mysql的可重复读、幻读及实现原理

事务隔离级别有四种,mysql默认使用的是可重复读,mysql是怎么实现可重复读的?为什么会出现幻读?是否解决了幻读的问题?

一、事务的隔离级别

Read Uncommitted(未提交读)
在该隔离级别,所有事务都可以看到其他未提交事务的执行结果。读取未提交的数据,也被称之为脏读(Dirty Read)。该级别用的很少。

Read Committed(提交读)
这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)。它满足了隔离的简单定义:一个事务只能看见已经提交事务所做的改变,换句话说就是事务提交之前对其余事务不可见。这种隔离级别也支持不可重复读(Nonrepeatable Read),因为同一事务的其他实例在该实例处理其间可能会有新的commit,所以同一select查询可能返回不同结果。

Repeatable Read(可重复读)
这是MySQL的默认事务隔离级别,它确保同一事务的多个实例在并发读取数据时,会看到同样的数据行。不过理论上,这会导致另一个棘手的问题:幻读 (Phantom Read)。简单的说,幻读指当用户读取某一范围的数据行时,另一个事务又在该范围内插入了新行,当用户再读取该范围的数据行时,会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制(MVCC,Multiversion Concurrency Control)机制解决了该问题(mysql彻底解决了幻读问题?请往下看)。

Serializable(可串行化)
这是最高的隔离级别,它强制事务都是串行执行的,使之不可能相互冲突,从而解决幻读问题。换言之,它是在每个读的数据行上加上共享锁。在这个级别,可能导致大量的超时现象和锁竞争。
 

事务隔离级别脏读不可重复读幻读
读未提交(read-uncommitted)
不可重复读(read-committed)
可重复读(repeatable-read)
串行化(serializable)

在MySQL的众多存储引擎中,只有InnoDB支持事务,所有这里说的事务隔离级别指的是InnoDB下的事务隔离级别。

二、mysql怎么实现的可重复读

MVCC多版本并发控制(Multi-Version Concurrency Control)是MySQL中基于乐观锁理论实现隔离级别的方式,用于实现读已提交和可重复读取隔离级别。

在《高性能MySQL》中对MVCC的解释如下

举例说明MVCC的实现

新建一张表test_zq如下

idtest_idDB_TRX_IDDB_ROLL_PT

MVCC逻辑流程-插入

在插入数据的时候,假设系统的全局事务ID从1开始,以下SQL语句执行分析参考注释信息:

begin;-- 获取到全局事务ID
insert into `test_zq` (`id`, `test_id`) values('5','68');
insert into `test_zq` (`id`, `test_id`) values('6','78');
commit;-- 提交事务
复制代码

当执行完以上SQL语句之后,表格中的内容会变成:

idtest_idDB_TRX_IDDB_ROLL_PT
5681NULL
6781NULL

可以看到,插入的过程中会把全局事务ID记录到列 DB_TRX_ID 中去

MVCC逻辑流程-删除

对上述表格做删除逻辑,执行以下SQL语句(假设获取到的事务逻辑ID为 3)

begin;--获得全局事务ID = 3
delete test_zq where id = 6;
commit;
复制代码

执行完上述SQL之后数据并没有被真正删除,而是对删除版本号做改变,如下所示:

idtest_idDB_TRX_IDDB_ROLL_PT
5681NULL
67813

MVCC逻辑流程-修改

修改逻辑和删除逻辑有点相似,修改数据的时候 会先复制一条当前记录行数据,同事标记这条数据的数据行版本号为当前是事务版本号,最后把原来的数据行的删除版本号标记为当前是事务。

执行以下SQL语句:

begin;-- 获取全局系统事务ID 假设为 10
update test_zq set test_id = 22 where id = 5;
commit;
复制代码

执行后表格实际数据应该是:

idtest_idDB_TRX_IDDB_ROLL_PT
568110
67813
52210NULL
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Zookeeper是一种分布式协调服务,而Paxos算法则是一种分布式一致性算法,Zookeeper使用Paxos算法来实现分布式数据一致性。下面是Paxos算法的原理及过程: 1. 提议阶段: Paxos算法的核心是通过多个节点之间的协商达成一致。一个节点想要在分布式系统中提交一个提议,首先需要向其他节点发送一个提议请求。每个节点收到提议请求后,会进行如下处理: a. 如果该节点没有收到过任何提议,则该节点会接受该提议。 b. 如果该节点已经收到过提议,但是该提议的编号小于当前提议的编号,则该节点会拒绝该提议,并回复当前提议的编号。 c. 如果该节点已经收到过提议,并且该提议的编号大于等于当前提议的编号,则该节点会接受该提议。 2. 学习阶段: 如果一个提议被超过一半的节点接受,则该提议成为了一个已经被接受的提议。如果一个节点收到了一个已经被接受的提议,则该节点会更新自己的状态,并通知其他节点该提议已经被接受。 3. 冲突处理: 如果两个节点同时向其他节点发送了提议请求,则会发生冲突。为了解决冲突,Paxos算法会在提议中增加一个唯一标识符,例如一个时间戳。这样,即使两个节点同时发送了提议请求,它们的提议也会有不同的编号和唯一标识符,从而避免冲突。 总体来说,Paxos算法通过多个节点之间的协商,实现了分布式系统中的数据一致性。Zookeeper使用Paxos算法来实现分布式数据一致性,从而保证了分布式系统中数据的正确性和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值