2022-01-09 ACID事务实现

原文链接：MySQL事务之ACID实现原理（全方位解读）_Maycope的博客-CSDN博客

前言

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

数据库中的事务包含四个特性：
1.原子性
指事务包含的所有操作要么成功，要么全部失败回滚。

2.一致性
一致性是指事务执行前后是从一个一致性状态变为另一个一致性状态。比如转账事务前后两个账户中金额相加应该是一致的。

3.隔离性
隔离性是指多个用户访问数据库时候，数据库会为每个用户开启相应的事务，每个用户的操作不受其他用户所影响，即使多个并发的事务也是互相隔离。

4.持久性
持久性是指事务一旦提交，数据库中的数据就是永久性的改变，数据库发生异常也不会丢失已经回滚已经提交了的数据。
————————————————
版权声明：本文为CSDN博主「猛浩」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/q1406689423/article/details/88638864

原子性

概念描述：原子性是指一个事务是一个不可分割的工作单位，其中的操作要么都做，要么全部做。如果对于一个事务来说其中的sql语句执行失败，则已经执行的语句也必须要回滚，数据库退回到事务之前的状态。

实现原理

对介绍原子性之前，对于Mysql的事务日志来说，InnoDB提供了两种事务日志： redo log(重做日志)和 undo log(回滚日志)。其中的重做日志保证的是事物的持久性，回滚日志保证的是事务的原子性和隔离性实现的基础。
下面来具体介绍对于原子性实现的关键： 当事务出现回滚时候能够撤销所有已经成功执行的sql语句。
InnoDB能够实现回滚的主要原因就是靠undo log： 当事务对数据库进行修改的时候，InnoDB会生成对应的undo log ；如果此时事务执行失败或者调动了 rollback，导致事务出现回滚情况，可以利用undo log中的信息将数据回滚到修改前的样子
undo log 属于一个逻辑日志，它用来记录的是sql执行相关的信息。对于一个insert语句在回滚时候会执行delete，相反也是如此。例如对于一个update在执行的时候，其生成的undolog 中会包含被修改的主键（以便知道修改了哪些行，修改了哪些列）以便在回滚时候能够使用这些记录的信息将数据还原到执行之前。

持久性

概念描述： 事务一旦提交，他对数据库的改变就是永久的，接下来的其他操作或是故障都不应该对其造成影响。

实现的原理

前面提到了InnoDB实现了两个事务日志，首先我们来聊一下redo log 存在的背景。

InnoDB作为MySQL的存储引擎（在5.1版本以后），数据是存放在磁盘中的，但如果每次读写数据都需要磁盘IO，效率会很低。为此，InnoDB提供了缓存(Buffer Pool)，Buffer Pool中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲：
当从数据库读取数据时，会首先从Buffer Pool中读取，如果Buffer Pool中没有，则从磁盘读取后放入Buffer Pool；当向数据库写入数据时，会首先写入Buffer Pool，Buffer Pool中修改的数据会定期刷新到磁盘中（这一过程称为刷脏）。

Buffer Pool的使用大大提高了读写数据的效率，但是也带了新的问题：如果MySQL宕机，而此时Buffer Pool中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证。

于是，redo log被引入来解决这个问题：当数据修改时，除了修改Buffer Pool中的数据，还会在redo log记录这次操作；当事务提交时，会调用fsync接口对redo log进行刷盘。如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复。redo log采用的是WAL（Write-ahead logging，预写式日志），所有修改先写入日志，再更新到Buffer Pool，保证了数据不会因MySQL宕机而丢失，从而满足了持久性要求。

既然redo log也需要在事务提交时将日志写入磁盘，为什么它比直接将Buffer Pool中修改的数据写入磁盘(即刷脏)要快呢？主要有以下两方面的原因：
（1）刷脏是随机IO，因为每次修改的数据位置随机，但写redo log是追加操作，属于顺序IO。
（2）刷脏是以数据页（Page）为单位的，MySQL默认页大小是16KB，一个Page上一个小修改都要整页写入；而redo log中只包含真正需要写入的部分，无效IO大大减少。

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

（1）作用不同：redo log是用于crash recovery的，保证MySQL宕机也不会影响持久性；binlog是用于point-in-time recovery的，保证服务器可以基于时间点恢复数据，此外binlog还用于主从复制。
（2）层次不同：redo log是InnoDB存储引擎实现的，而binlog是MySQL的服务器层(可以参考文章前面对MySQL逻辑架构的介绍)实现的，同时支持InnoDB和其他存储引擎。
（3）内容不同：redo log是物理日志，内容基于磁盘的Page；binlog的内容是二进制的，根据binlog_format参数的不同，可能基于sql语句、基于数据本身或者二者的混合。
（4）写入时机不同：binlog在事务提交时写入；redo log的写入时机相对多元：

前面曾提到：当事务提交时会调用fsync对redo log进行刷盘；这是默认情况下的策略，修innodb_flush_log_at_trx_commit参数可以改变该策略，但事务的持久性将无法保证。
除了事务提交时，还有其他刷盘时机：如master thread每秒刷盘一次redo log等，这样的好处是不一定要等到commit时刷盘，commit速度大大加快。

隔离性

定义：与原子性，持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的相互影响。是指，事务内部的操作与其他的事务是隔离的，并发执行的各个事务之间是不能相互干扰。隔离性，对应了事务隔离级别中的 Serializable，但是在我们的实际的开发中很少使用到可串行化。
隔离性追求的是并发情形下事务之间不会相互干扰，简单起见，我们仅考虑最简单的读操作和写操作(暂时不考虑带锁读等特殊操作)，那么隔离性的探讨，主要可以分为两个方面：

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

锁机制

首先来看两个事务的写操作之间的相互影响。隔离性要求同一时刻只能有一个事务对数据进行写操作，InnoDB通过锁机制来保证这一点。
锁机制的基本原理可以概括为：
事务在修改数据之前，需要先获得相应的锁；获得锁之后，事务便可以修改数据；该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁。

行锁与表锁

按照粒度，分为表锁与行锁：
MyISAM 支持表锁，InnoDB 支持表锁和行级锁，默认是行级锁。
表级锁：开销小，加锁快，不会出现死锁。锁定粒度大，发送锁冲突的概率比较高，并发处理效果较低。
行级锁： 开销大，加锁慢，会出现死锁，锁定粒度较大，发生锁冲突的概率会小一点，并发处理的效果高

下面开始介绍事务过程中的可能出现的情况，其实下面所介绍的也都是与锁隔离性相关的问题： 先来介绍一下可能出现的问题：
脏读，不可重复读和幻读（就是并发问题）

类型	解析
幻读	事务T1读取一条指定where条件的语句，返回结果集。此时事务T2插入一行新记录，恰好满足T1的where条件。然后T1使用相同的条件再次查询，结果集中可以看到T2插入的记录，这条新记录则是幻读记录
不可重复读取	事务T1读取一行记录，紧接着事务T2修改了T1刚刚读取的记录，然后T1再次查询，发现与第一次读取的记录不同，这称为不可重复读
脏读	事务T1更新了一行记录，还未提交所做的修改，这个T2读取了更新后的数据，然后T1执行回滚操作，取消刚才的修改，所以T2所读取的行就失效，也就是脏数据

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

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

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

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

能够具体解决的问题：

事务隔离级别	脏读	不可重复读	幻读
读未提交	是	是	是
不可重复读	否	是	是
可重复读	否	否	是
串行化	否	否	否

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

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

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

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

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

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

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

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

保证原子性、持久性和隔离性，如果这些特性无法保证，事务的一致性也无法保证
数据库本身提供保障，例如不允许向整形列插入字符串值、字符串长度不能超过列的限制等
应用层面进行保障，例如如果转账操作只扣除转账者的余额，而没有增加接收者的余额，无论数据库实现的多么完美，也无法保证状态的一致
总结：
下面来总结一下 ACID （最后篇）

原子性： 语句要么都执行，要么都不是执行，是事务最核心的特性，事务本身来说就是以原子性历来定义的，实现主要是基于undo log
持久性： 保证事务提交之后，不会因为宕机等其他的原因而导致数据的丢失，主要是基于 redo log实现
隔离性： 保证事务与事务之间的执行是相互隔离的，事务的执行不会受到其他事务的影响。InnoDB存储引擎默认的数据库隔离级别是 RR ，RR又主要是基于锁机制，数据的隐藏列，undo log类 以及 next-key lock机制
一致性： 事务追求的最终目标，一致性的实现即需要数据库层面的保障，也需要应用层面的保障。