MYSQL事务之ACID实现原理

MYSQL事务之ACID实现原理
我们都知道MySQL事务的ACID，但是按照严格的标准，只有同时满足ACID特性才是事务；但是在各大数据库厂商的实现中，真正满足ACID的事务少之又少。例如MySQL的NDB Cluster事务不满足持久性和隔离性；InnoDB默认事务隔离级别是可重复读，不满足隔离性；Oracle默认的事务隔离级别为READ COMMITTED，不满足隔离性…… ​ 因此与其说ACID是事务必须满足的条件，不如说它们是衡量事务的四个维度。很多的文章也都会介绍事务ACID是什么，但是却很少有人能够介绍到事务ACID的实现原理。今天这里就来介绍一下实现原理。

原子性
1.概念
原子性是指一个事务是一个不可分割的工作单位，其中的操作要么都做，要么都不做。对于一个已经开始执行的事务来说，其中的sql

语句执行失败，那么当前事务中已执行的其他sql语句也必须要进行回滚，回到事务开始之前的状态

2.实现原理
对介绍原子性之前，对于Mysql的事务日志来说，InnoDB提供了两种事务日志： redo log(重做日志)和 undo log(回滚日志)。其中的重做日志保证的是事物的持久性，回滚日志保证的是事务的原子性和隔离性

原子性实现的关键：当事务出现回滚时，能撤销所有已经执行的sql语句

Innodb实现回滚主要依靠的时undo log：当事务对数据库进行修改时，Innodb会生成对应的undo log；如果事务执行失败了或手动调用了roll back，将导致事务进行回滚，可以利用undo log中的信息将数据回滚到事务开始之前的样子

undo log 属于一个逻辑日志，它用来记录的时sql执行相关的信息。对于一个已经执行的insert语句在回滚的时候会执行delete语句，相反亦是如此。对于一个update在执行的时候，其生成的undo log会包含被修改的主键(以便知道修改了哪些行，修改了哪些列)，在回滚的时候使用这些记录的信息将数据恢复到执行之前

持久性
1.概念
事务一旦提交，它对数据库的改变就是永久的，接下来的其他操作或者是故障都不会对其造成影响

2.实现原理
前面提到过，redo log 是保证事务持久性的

Innodb在MYSQL5.1后出现的，作为MYSQL的存储引擎，数据是存放在磁盘中的，但如果每次读写数据都需要IO，效率非常低。为此，Innodb提供了缓存(Buffer Pool)，缓存中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲；

当从数据库读取数据时，会先从缓存中读取，如果缓存中读取不到，则回去磁盘中读取并放入缓存中；当向数据库写入数据时，会先写入缓存中，缓存中修改的数据会定时刷新到磁盘中(这一过程称为刷脏)

3.缓存

Buffer Pool的使用大大提高了读写数据的效率，但同时也会带来数据不一致的问题：比如数据写入到缓存中时，此时Mysql宕机了，数据还未写入磁盘中，会导致数据的丢失，保证不了事务的持久性

解决办法：引入了redo log

当数据修改时，除了修改Buffer Pool的数据，还会在redo log中记录这次操作；当事务提交时，会调用fsync接口对redo log进行刷盘。如果MYSQL宕机，重启时读取redo log中的数据，对数据库进行恢复。redo log采用的是预写式日志(Write-ahead logging)，所有的修改操作，会先写入redo log中，再写入Buffer Pool。保证了数据不会因为MYSQL宕机而丢失，从而满足了持久性的要求

既然redo log也需要在事务提交时将日志写入磁盘，为什么它比直接将Buffer Pool中修改的数据写入磁盘(即刷脏)要快呢？主要有以下两方面的原因：

刷脏是随机的。因为每次修改的数据位置随机，但是redo log属于追加操作，属于顺序IO

刷脏是以Page(数据页)为单位的。MySQL默认数据页大小是16KB，一个Page上一个小修改都要整页写入。而redo log只包含真正要写入的部分，无效IO大大减小(比如对同一条数据进行了插入和删除操作)

4.redo log 和 binlog
在MySQL中还存在binlog(二进制日志)也可以记录写操作并用于数据的恢复，但二者是有着根本的不同的：

1.作用不同。redo log是作用于crash recovery的，保证MySQL宕机也不会影响事务的持久性；binlog是用于`point-in-time recovery的，保证服务器可以基于时间点恢复数据，binlog还可以用于主从复制

2.层次不同。redo log是Innodb存储引擎实现的，而binlog是MySQL的服务器层实现的，同时支持Inndb和其他存储引擎

3.内容不同。rede log是物理日志，内容基于磁盘的Page。而binlog的内容是二进制的，根据binlog_format的参数不同，可能基于sql语句，基于数据本事或者二者的混合

4.写入时机不同。redo log写入时机是随机的。binlog是在事务提交时写入的

前面提到的：当事务提交时会调用fsync对redo log进行刷盘，这是默认策略。该策略可以修改，但事务的持久性无法保证

除了事务提交时，还有其他刷盘时机：对master thread每秒刷盘一次redo log等，不必等到事务提交时再刷盘，提交速度大大提高

隔离性
1.概念
与原子性，持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的相互影响。是指，事务内部的操作与其他的事务是隔离的，并发执行的各个事务之间是不能相互干扰。隔离性，对应了事务隔离级别中的 Serializable(可串行化)，但是在我们的实际的开发中很少使用到可串行化。

隔离性追求的是并发情形下事务之间不会相互干扰，简单起见，我们仅考虑最简单的读操作和写操作(暂时不考虑带锁读等特殊操作)，那么隔离性的探讨，主要可以分为两个方面：

(一个事务)写操作对(另一个事务)写操作的影响：锁机制保证隔离性

(一个事务)写操作对(另一个事务)读操作的影响：MVCC保证隔离性

2.锁机制
隔离性要求同一时刻只能有一个事务对数据进行写操作，InnoDB通过锁机制来保证这一点。 ​ 锁机制的基本原理可以概括为：

事务在修改数据之前，需要先获得相应的锁；获得锁之后，事务便可以修改数据；该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁。

行锁和表锁：

按照粒度，分为表锁与行锁：

表级锁	行级锁

MyISAM √ ❌
Innodb √ √(默认情况下)
特点 开销小，加锁快，不会出现死锁。锁定粒度大，发送锁冲突的概率比较高，并发处理效果较低。 开销大，加锁慢，会出现死锁，锁定粒度较大，发生锁冲突的概率会小一点，并发处理的效果高
并发情况下会出现的问题：

在这里插入图片描述

3.MySQL的隔离级别
未提交读（RU） 所有事务都可以看到其他未提交事务的执行结果， 即在未提交读级别，事务的修改，即使没有提交，对其他事务也是可见的，该隔离级别很少使用到，也被称为脏读。

提交读（RC） 大多数的数据库默认的隔离级别是 提交读，但是对于Mysql不是 提交读：一个事务开始时，只能“看见”已经提交的事物所做的修改。换句话说一个事务从开始直到提交之前，所做的任何修改都是对其他事务不可见的。这个级别也叫作不可重复读。

可重复读（RR） 解决了脏读了问题，该级别保证了在同一个事务多次读取同样记录的结果是一致的。但是可重复读还是无法解决幻读的问题： 什么是幻读 指的是当某个事务在读取某个范围内的记录的时候，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时候 就会产生 幻行。InnoDB 和XtraDB 存储引擎通过版本并发控制解决而了幻读的问题可重复读是Mysql的事务的默认隔离级别。注意在 SQL标准中，RR是无法避免幻读问题，但是InnoDB实现的RR避免了幻读问题。

可串行化读 是最高的隔离级别，通过强制事务串行化执行(即事务排队执行，不会出现并发)，避免了前面所说到的幻读的问题。就是可串行化 会在读取的每一行数据上都加上锁，但是这样会导致超时和锁争用问题。

不同隔离级别能够解决的问题

在这里插入图片描述

MVCC
1.概念
前面讲到了 RR解决了 脏读，不可重复读，幻读等问题使用到的就是MVCC（Multi-Version Concurrency Control） 既多版本的并发控制：在同一个时刻，不同的事物读取到的数据可能是不同的（多版本）。对于MVCC来说最大的优点就是读不加锁，因此读写不冲突，并发性能好 ​ InnoDB实现MVCC，多个版本的数据可以共存，主要是依靠数据的隐藏列(也可以称之为标记位)和undo log。其中数据的隐藏列包括了该行数据的版本号、删除时间、指向undo log的指针等等；当读取数据时，MySQL可以通过隐藏列判断是否需要回滚并找到回滚需要的undo log，从而实现MVCC。

2.如何解决脏读在这里插入图片描述
当事务A在T3时间节点读取zhangsan的余额时，会发现数据已被其他事务修改，且状态为未提交。此时事务A读取最新数据后，根据数据的undo log执行回滚操作，得到事务B修改前的数据，从而避免了脏读

3. 如何解决不可重复读在这里插入图片描述
   当事务A在T2节点第一次读取数据时，会记录该数据的版本号（数据的版本号是以row为单位记录的），假设版本号为1；当事务B提交时，该行记录的版本号增加，假设版本号为2；当事务A在T5再一次读取数据时，发现数据的版本号（2）大于第一次读取时记录的版本号（1），因此会根据undo log执行回滚操作，得到版本号为1时的数据，从而实现了可重复读。

4.如何解决幻读
InnoDB实现的RR通过next-key lock机制避免了幻读现象。

next-key lock是行锁的一种，实现相当于record lock(记录锁) + gap lock(间隙锁)；其特点是不仅会锁住记录本身(record lock的功能)，还会锁定一个范围(gap lock的功能)。当然，这里我们讨论的是不加锁读：此时的next-key lock并不是真的加锁，只是为读取的数据增加了标记（标记内容包括数据的版本号等）；

在这里插入图片描述

当事务A在T2节点第一次读取0<id<5数据时，标记的不只是id=1的数据，而是将范围(0,5)进行了标记，这样当T5时刻再次读取0<id<5数据时，便可以发现id=2的数据比之前标记的版本号更高，此时再结合undo log执行回滚操作，避免了幻读。

概括来说，InnoDB实现的RR，通过锁机制、数据的隐藏列、undo log和类next-key lock，实现了一定程度的隔离性，可以满足大多数场景的需要。不过需要说明的是，RR虽然避免了幻读问题，但是毕竟不是Serializable，不能保证完全的隔离。

一致性
1.概念
一致性是指事物执行结束后，数据库的完整性没有被破坏，事务执行的前后都是合法的数据状态。数据库的完整性包括但是不限于： 实体完整性（如行的主键存在且唯一），列完整性（如字段的类型，大小，长度符合要求），外键约束（外键约束还存在），用户自定义完整性（如转账前后，两个账户的和应该是不变的）

2.实现
可以说，一致性是事物追求的最终目标，前面提到的原子性，隔离性，持久性都是为了保证数据库的一致性。此外除了数据库底层的保障，一致性的实现也需要应用层的保障。

保证原子性、持久性和隔离性，如果这些特性无法保证，事务的一致性也无法保证

数据库本身提供保障，例如不允许向整形列插入字符串值、字符串长度不能超过列的限制等

应用层面进行保障，例如如果转账操作只扣除转账者的余额，而没有增加接收者的余额，无论数据库实现的多么完美，也无法保证状态的一致

总结
原子性： 语句要么都执行，要么都不是执行，是事务最核心的特性，事务本身来说就是以原子性历来定义的，实现主要是基于undo log

持久性： 保证事务提交之后，不会因为宕机等其他的原因而导致数据的丢失，主要是基于 redo log实现

隔离性： 保证事务与事务之间的执行是相互隔离的，事务的执行不会受到其他事务的影响。InnoDB存储引擎默认的数据库隔离级别是 RR ，RR又主要是基于锁机制，数据的隐藏列，undo log类 以及 next-key lock机制

一致性： 事务追求的最终目标，一致性的实现即需要数据库层面的保障，也需要应用层面的保障。