Mysql事务回滚机制与原理

最新推荐文章于 2024-05-02 15:14:00 发布

九离⠂

最新推荐文章于 2024-05-02 15:14:00 发布

阅读量3k

点赞数 5

分类专栏： # Mysql 文章标签： mysql 数据库 java

本文链接：https://blog.csdn.net/qq_43410878/article/details/125745445

版权

Mysql 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

Mysql事务回滚机制与原理

文章目录

- Mysql事务回滚机制与原理

一、事务回滚机制

其实，讨论MySQL的事务回滚机制，也就是在说MySQL的事务原子性是如何实现的。所谓原子性，就是指一个事务是一个不可分割的工作单位，其中的操作要么都做，要么都不做；如果事务中的一个sql语句执行失败，则已执行的语句必须回滚，数据库会退回到事务前的状态。我们可以这么理解，就是说如果事务失败了，那么它对我们的数据库是没有任何影响的。

二、使用到的技术讨论

提出一个问题：

事务想要做到什么效果？

在我看来，其实就是要做到可靠性和并发处理

可靠性：数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个，我需要知道我修改之前和修改之后的状态。所有以就有了undo log和redo log。

并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会有影响，为了避免读到脏数据，所以需要对事务之间的读写进行隔离，至于隔离到啥程度就看业务系统的场景了，实现这个就得用mysql的隔离级别。

三、redo log和undo log介绍

3.1 redo log

redo log 叫做重做日志，redo log用于保证事务持久性。undo log属于逻辑日志，它记录的redo log叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲(redo log buffer)以及重做日志文件(redo log),前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中。假设有个表叫做tb1(id,username) 现在要插入数据(3，ceshi)

假设场景：
start transaction;

select balance from bank where name="zhangsan";

// 生成 重做日志 balance=600

update bank set balance = balance - 400;

// 生成 重做日志 amount=400

update finance set amount = amount + 400;

commit;

redo log的作用？

mysql 为了提升性能不会把每次的修改都实时同步到磁盘，而是会先存到Boffer Pool(缓冲池)里头，把这个当作缓存来用。然后使用后台线程去做缓冲池和磁盘之间的同步。

那么问题来了，如果还没来的同步的时候宕机或断电了怎么办？还没来得及执行上面图中红色的操作。这样会导致丢部分已提交事务的修改信息！

所以引入了redo log来记录已成功提交事务的修改信息，并且会把redo log持久化到磁盘，系统重启之后在读取redo log恢复最新数据。

即redo log是用来恢复数据的用于保障，已提交事务的持久化特性。

3.2 undo log

undo log是事务原子性和隔离性实现的基础。

之所以能够保证原子性，则是靠undo log。当事务对数据库进行修改时，InnDB会生成对应的undo log；如果事务失败或者调用了rollback，导致事务回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。

undo log属于逻辑日志，它记录的是sql执行相关的信息。当发生回滚时，InnoDB会根据undo log的内容做与之前相反的工作：对于每个insert，回滚时会执行delete；对于每个delete，回滚时会执行insert；对于每个update，回滚时会执行一个相反的update，把数据改回去。

以update操作为例：当事务执行update时，其生成的undo log中会包含被修改行的主键(以便知道修改了哪些行)、修改了哪些列、这些列在修改前后的值等信息，回滚时便可以使用这些信息将数据还原到update之前的状态。

每次写入数据或者修改数据之前都会把修改前的信息记录到undo log

四、mysql锁技术以及MVCC基础

4.1 mysql锁技术

当有多个请求来读取表中的数据时可以不采取任何操作，但是多个请求里有读请求，又有修改请求时必须有一种措施来进行并发控制。不然很有可能会造成不一致。

读写锁

解决上述问题很简单，只需用两种锁的组合来对读写请求进行控制即可，这两种锁被称为：

共享锁(shared lock),又叫做"读锁"

读锁是可以共享的，或者说多个读请求可以共享一把锁读数据，不会造成阻塞。

排他锁(exclusive lock),又叫做"写锁"

写锁会排斥其他所有获取锁的请求，一直阻塞，直到写入完成释放锁。

通过读写锁，可以做到读读可以并行，但是不能做到写读，写写并行

事务的隔离性就是根据读写锁来实现的！

4.2 MVCC基础

MVCC (MultiVersion Concurrency Control) 叫做多版本并发控制。
InnoDB的 MVCC ，是通过在每行记录的后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存了行的过期时间，当然存储的并不是实际的时间值，而是系统版本号。

以上片段摘自《高性能Mysql》这本书对MVCC的定义。他的主要实现思想是通过数据多版本来做到读写分离。从而实现不加锁读进而做到读写并行。

MVCC在mysql中的实现依赖的是undo log与read view
undo log :undo log 中记录某行数据的多个版本的数据。
read view :用来判断当前版本数据的可见性

五、事务的实现

事务的原子性是通过 undo log 来实现的

事务的持久性性是通过 redo log 来实现的

事务的隔离性是通过 (读写锁+MVCC)来实现的

而事务的终极大 boss 一致性是通过原子性，持久性，隔离性来实现的！！！

原子性，持久性，隔离性折腾半天的目的也是为了保障数据的一致性！

5.1 原子性的实现

一个事务必须被视为不可分割的最小工作单位，一个事务中的所有操作要么全部成功提交，要么全部失败回滚，对于一个事务来说不可能只执行其中的部分操作，这就是事务的原子性。

所谓回滚操作就是当发生错误异常或者显式的执行rollback语句时需要把数据还原到原先的模样，所以这时候就需要用到undo log来进行回滚，接下来看一下undo log在实现事务原子性时怎么发挥作用的:

假设有两个表 bank和finance，表中原始数据如图所示，当进行插入，删除以及更新操作时生成的undo log如下面图所示：

为了做到同时成功或者失败，当系统发生错误或者执行rollback操作时需要根据undo log 进行回滚

5.2 持久性的实现

事务一旦提交，其所作做的修改会永久保存到数据库中，此时即使系统崩溃修改的数据也不会丢失。

先了解一下MySQL的数据存储机制，MySQL的表数据是存放在磁盘上的，因此想要存取的时候都要经历磁盘IO,然而即使是使用SSD磁盘IO也是非常消耗性能的。

为此，为了提升性能InnoDB提供了缓冲池(Buffer Pool)，Buffer Pool中包含了磁盘数据页的映射，可以当做缓存来使用：

读数据：会首先从缓冲池中读取，如果缓冲池中没有，则从磁盘读取在放入缓冲池；

写数据：会首先写入缓冲池，缓冲池中的数据会定期同步到磁盘中；

上面这种缓冲池的措施虽然在性能方面带来了质的飞跃，但是它也带来了新的问题，当MySQL系统宕机，断电的时候可能会丢数据！！！

因为我们的数据已经提交了，但此时是在缓冲池里头，还没来得及在磁盘持久化，所以我们急需一种机制需要存一下已提交事务的数据，为恢复数据使用。

于是 redo log就派上用场了.

既然redo log也需要存储，也涉及磁盘IO为啥还用它？

(1)redo log 的存储是顺序存储，而缓存同步是随机操作。

(2)缓存同步是以数据页为单位的，每次传输的数据大小大于redo log。

5.3 隔离性实现

隔离性是事务ACID特性里最复杂的一个。在SQL标准里定义了四种隔离级别，每一种级别都规定一个事务中的修改，哪些是事务之间可见的，哪些是不可见的。

级别越低的隔离级别可以执行越高的并发，但同时实现复杂度以及开销也越大。

Mysql 隔离级别有以下四种(级别由低到高)：

READ UNCOMMITED (未提交读) < READ COMMITED (提交读) < REPEATABLE READ (可重复读) < SERIALIZABLE (可重复读)

隔离性是要管理多个并发读写请求的访问顺序。这种顺序包括串行或者是并行

从隔离性的实现可以看出这是一场数据的可靠性与性能之间的权衡。

可靠性性高的，并发性能低(比如 Serializable)

可靠性低的，并发性能高(比如 Read Uncommited)

READ UNCOMMITTED

在READ UNCOMMITTED隔离级别下，事务中的修改即使还没提交，对其他事务是可见的。事务可以读取未提交的数据，造成脏读。

因为读不会加任何锁，所以写操作在读的过程中修改数据，所以会造成脏读。好处是可以提升并发处理性能，能做到读写并行。换句话说，读的操作不能排斥写请求。

READ COMMITTED

一个事务的修改在他提交之前的所有修改，对其他事务都是不可见的。其他事务能读到已提交的修改变化。在很多场景下这种逻辑是可以接受的。
InnoDB在 READ COMMITTED，使用排它锁,读取数据不加锁而是使用了MVCC机制。或者换句话说他采用了读写分离机制。但是该级别会产生不可重读以及幻读问题。
什么是不可重读？在一个事务内多次读取的结果不一样。为什么会产生不可重复读？这跟 READ COMMITTED 级别下的MVCC机制有关系，在该隔离级别下每次 select的时候新生成一个版本号，所以每次select的时候读的不是一个副本而是不同的副本。在每次select之间有其他事务更新了我们读取的数据并提交了，那就出现了不可重复读

REPEATABLE READ(Mysql默认隔离级别)

在一个事务内的多次读取的结果是一样的。这种级别下可以避免，脏读，不可重复读等查询问题。mysql 有两种机制可以达到这种隔离级别的效果，分别是采用读写锁以及MVCC。

采用读写锁实现：

为什么能可重复度？只要没释放读锁，在次读的时候还是可以读到第一次读的数据。

优点：实现起来简单

缺点：无法做到读写并行

采用MVCC实现：

为什么能可重复度？因为多次读取只生成一个版本，读到的自然是相同数据。

优点：读写并行

缺点：实现的复杂度高

但是在该隔离级别下仍会存在幻读的问题

SERIALIZABLE

该隔离级别理解起来最简单，实现也最单。在隔离级别下除了不会造成数据不一致问题，没其他优点。

5.4 一致性实现

数据库总是从一个一致性的状态转移到另一个一致性的状态.

下面举个例子:zhangsan 从银行卡转400到理财账户

start transaction;

select balance from bank where name=“zhangsan”;

// 生成重做日志 balance=600

update bank set balance = balance - 400;

// 生成重做日志 amount=400

update finance set amount = amount + 400;

commit;

1.假如执行完 update bank set balance = balance - 400;之发生异常了，银行卡的钱也不能平白无辜的减少，而是回滚到最初状态。

2.又或者事务提交之后，缓冲池还没同步到磁盘的时候宕机了，这也是不能接受的，应该在重启的时候恢复并持久化。