既然undo log和redo log都是从log buffer 到 OS buffer,再到磁盘。所以中途还是有可能因为断电/硬件故障等原因导致日志丢失。为此MySQL提供了三种持久化方式:这里有一个参数 innodb_flush_log_at_trx_commit
,这个参数主要控制InnoDB将log buffer中的数据写入OS buffer,并刷到磁盘的时间点,取值分别为0,1,2,默认是1。这三个值的意思如下图所示:
首先查看MySQL默认设置的方式1,也就是每次提交后直接写入OS buffer,并且调用系统函数fsync()把日志写到磁盘上。就保证数据一致性的角度来说,这种方式无疑是最安全的。但是我们都知道,安全大多数时候意味着效率偏低。每次提交都直接写入OS buffer并且写到磁盘,无疑会导致单位时间内IO的次数过多而效率低下。除此之外,还有方式0和方式2。基本上都是每秒写入磁盘一次,所以效率都比方式1更高。但是方式0是把数据先写入log buffer再写入OS buffer再写入磁盘,而方式2是直接写入OS buffer,再写入磁盘,少了一次数据拷贝的过程(从log buffer到OS buffer),所以方式2比方式0更加高效。
了解了undo log和redo log的作用和实现机制之后,那么这两个日志具体是怎么让数据库从异常的状态恢复到正常状态的呢?
数据库系统崩溃后重启,此时数据库处于不一致的状态,必须先执行一个crash recovery的过程:首先读取redo log,把成功提交但是还没来得及写入磁盘的数据重新写入磁盘,保证了持久性。再读取undo log将还没有成功提交的事务进行回滚,保证了原子性。crash recovery结束后,数据库恢复到一致性状态,可以继续被使用。
2.3 隔离性
数据库事务的隔离性是指:多个事务并发执行时,一个事务的执行不应影响其他事务的执行。正常情况下,肯定是多个事务同时操作同一个数据库,所以事务之间的隔离就显得必不可少。
如果没有隔离性,将会发生以下问题:
2.3.1 第一类丢失更新
一个事务在撤销的时候,覆盖了另一个事务已提交的更新数据。 假设现在有两个事务A、B同时操作同一账户的金额,如下图所示:
显然,事务B在撤销事务的时候,覆盖了事务A在T4阶段已经提交的更新数据。A在T3的时候已经取走了200元,此时的余额应该是800元,但是由于事务B开始的时候,余额是1000元,所以回滚后,余额也会变成1000元。这样一来,用户明明取了钱,但是余额不变,银行亏到姥姥家了。
2.3.2 脏读
一个事务读到了另一个事务未提交的更新数据。
用下图说明:
事务A在T3的时候取走了200元,但是未提交。事务B在T4时查询余额就能看到事务A未提交的更新。
2.3.3 幻读
幻读(虚读)是指:一个事务读到了另一个事务已提交的新增数据。
依然是配图说明:
事务B在同一个事务中执行两次统计操作之间,另一事务insert了一条记录,导致得到的结果不一样,好像发生了幻觉。还有一种情况是事务B更新了表中所有记录的某一字段,之后事务A又插入了一条记录,事务B再去查询发现有一条记录没有被更新,这也是幻读。
2.3.4 不可重复读
不可重复读:一个事务读到了另一个事务已提交的更新数据。
不可重复读,顾名思义,就是在同一个事务中重复读取数据会发生不一致的情况,如下图:
事务B在T2和T5阶段都执行了查询余额的操作,但是每次得到的结果都不一样,这在开发中是不允许的,同一个事务中同样的多次查询,每次返回不一样的结果,让人不免会对数据库的可靠性产生怀疑。
2.3.5 第二类丢失更新
一个事务在提交的时候,覆盖了另一个事务已提交的更新数据。
由上图可以看出,当事务A提交之后,账户余额已经发生了变动,然后事务B还是基于原始金额(即1000)的基础上扣除取款金额的,事务B以提交,就是把事务A的提交给完全覆盖了。此为第二类丢失更新。
注意和第一类丢失更新区分,第一类丢失更新重点在事务B最终撤销了事务,第二类是最终提交了事务。
为了解决这五类问题,MySQL提供了四种隔离级别:
- Serializable(串行化) :事务之间以一种串行的方式执行,安全性非常高,效率低
- Repeatable Read(可重复读) :是MySQL默认的隔离级别,同一个事务中相同的查询会看到同样的数据行,安全性较高,效率较好
- Read Commited(读已提交) :一个事务可以读到另一个事务已经提交的数据,安全性较低,效率较高
- Read Uncommited(读未提交) :一个事务可以读到另一个事务未提交的数据,安全性低,效率高
3、Repeatable Read
Repeatable Read(可重复读)是MySQL默认的隔离级别,也是使用最多的隔离级别,所以单独拿出来深入理解很有必要。Repeatable Read无法解决幻读(虚读)问题。下面来看一个实例。
首先创建一个表并插入一条记录:
CREATE TABLE student
(
id
bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT ‘主键’,
stu_id
bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘学生学号’,
stu_name
varchar(100) DEFAULT NULL COMMENT ‘学生姓名’,
created_date
datetime NOT NULL COMMENT ‘创建时间’,
modified_date
datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT ‘修改时间’,
ldelete_flag
tinyint(1) NOT NULL DEFAULT ‘0’ COMMENT ‘逻辑删除标志,0:未删除,2:已删除’,
PRIMARY KEY (id
)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT=‘学生信息表’;
INSERT INTO student
VALUES (1, 230160340, ‘Carson’, ‘2016-08-20 16:37:00’, ‘2016-08-31 16:37:05’, 0);
同样的开启两个事务,如下表所示:
按照上述理论,会出现幻读现象。也就是事务A在T4时间段的查询select会看到事务B提交的新增数据。
但让你失望了。
执行结果如下
和预期的结果并不一致,没有出现幻读现象。
实际上MySQL在Repeatable Read隔离级别下,用MVCC(Multiversion Concurrency Control,多版本并发控制)解决了select普通查询的幻读现象。
具体的实现方式就是事务开始时,第一条select语句查询结果集会生成一个快照(snapshot),并且这个事务结束前,同样的select语句返回的都是这个快照的结果,而不是最新的查询结果,这就是MySQL在Repeatable Read隔离级别对普通select语句使用的快照读(snapshot read)。
快照读和MVCC是什么关系?
MVCC是多版本并发控制,快照就是其中的一个版本。所以可以说MVCC实现了快照读,具体的实现方式涉及到MySQL的隐藏列。MySQL会给每个表自动创建三个隐藏列:
- DB_TRX_ID:事务ID,记录操作(增、删、改)该数据事务的事务ID
- DB_ROLL_PTR:回滚指针,记录上一个版本的数据在undo log中的位置
- DB_ROW_ID:隐藏ID ,创建表没有合适的索引作为聚簇索引时,会用该隐藏ID创建聚簇索引
由于undo log中记录了各个版本的数据,并且通过DB_ROLL_PTR可以找到各个历史版本,并且由DB_TRX_ID决定使用哪个版本(快照)。所以相当于undo log实现了MVCC,MVCC实现了快照读。
如此看来,MySQL的Repeatable Read隔离级别利用快照读,已经解决了幻读的问题。
但是事实并非如此,接下来再看一个例子
事务A在T1的时候生成快照,事务B在T2的时候插入一条数据Luffy,然后提交。在T4的时候把Luffy更新成Katakuri,根据上一个例子的经验,此时事务A是看不到Luffy这条数据的,所以更新也不会成功,并且在T5的时候查询,和T1时候一样,只有Carson和Kata两条数据。
但是,又要让你失望了
执行结果如下
但是执行结果却不是预期的那样,事务A不仅看到了Luffy,还把它成功的改成了Katakuri。即使事务A成功commit之后,再次查询还是这样。
这其实是MySQL对insert、update和delete语句所使用的当前读(current read)。因为涉及到数据的修改,所以MySQL必须拿到最新的数据才能修改,所以涉及到数据的修改肯定不能使用快照读(snapshot read)。由于事务A读到了事务B已提交的新增数据,所以就产生了前文所说的幻读。
那么在Repeatable Read隔离级别是怎么解决幻读的呢?
是通过间隙锁(Gap Lock)来解决的。我们都知道InnoDB支持行锁,并且行锁是锁住索引。而间隙锁用来锁定索引记录间隙,确保索引记录的间隙不变。间隙锁是针对事务隔离级别为Repeatable Read或以上级别而设的,间隙锁和行锁一起组成了Next-Key Lock。当InnoDB扫描索引记录的时候,会首先对索引记录加上行锁,再对索引记录两边的间隙加上间隙锁(Gap Lock)。加上间隙锁之后,其他事务就不能在这个间隙插入记录。这样就有效地防止了幻读的发生。
默认情况下,InnoDB工作在Repeatable Read的隔离级别下,并且以Next-Key Lock的方式对索引行进行加锁。当查询的索引具有唯一性(主键、唯一索引)时,Innodb存储引擎会对Next-Key Lock进行优化,将其降为行锁,仅仅锁住索引本身,而不是范围(除非锁定不存在的值)。若是普通索引,则会使用Next-Key Lock将记录和间隙一起锁定。
最后
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助。
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,不论你是刚入门Java开发的新手,还是希望在技术上不断提升的资深开发者,这些资料都将为你打开新的学习之门!
如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
*
如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!