InnoDB存储引擎底层拆解：从页、事务到锁，如何撑起MySQL数据库高效运转（下）

什么是undo log

事务是需要保证原子性的，也就是说，事务中的操作要么全部完成，要么什么也不做。但有如下情况，会造成事务执行不完：①事务执行过程中可能遇到各种错误，比如：服务器宕机，操作系统异常，突然断电……②程序员在事务执行过程中手动输入rollback语句结束当前事务的执行。

遇到上面的情况，为了保证事务的原子性，我们需要把数据还原回原来的样子，这个过程就叫做回滚（rollback）数据库为了回滚而记录的日志，我们就称之为撤销日志（undo log）

注意一点，由于SELECT操作并不会修改任何记录，所以并不需要记录相应的undo日志

如何开启事务

何时分配事务id

只有在事务对表中的记录进行改动时才会为这个事务分配一个唯一的事务id，否则事务id值默认为0。

只读事务何时分配事务id？只有在它第一次对某个用户创建的临时表（CREATE TEMPORARY TABLE）执行增删改操作时，才会为这个事务分配一个事务id，否则是不分配的。 读写事务何时分配事务id？只有在它第一次对某个表（包括用户创建的临时表）执行增删改操作时，才会为这个事务分配一个事务id，否则是不分配的。

事务id是怎么生成的

事务id本质上就是一个数字，事务id生成策略如下：① 内存中维护一个全局变量，每当需要为某个事务分配事务id时，就会把该变量值当作事务id分配给该事务，并且自增1。② 每当这个变量的值为256的倍数时，就会将值刷新到系统表空间中页号为5的页面中一个名为Max Trx ID的属性中（占用8个字节）。③ 当系统下一次启动时，会将Max Trx ID的值加载到到内存中，并加上256之后赋值给前面提到的全局变量。

为什么要加256？

答：因为上次关机时，该全局变量的值可能大于磁盘页面中的Max Trx ID属性值。

事务id在记录中存储的位置

trx_id表示对该条记录进行改动的语句所对应的事务id。

​

不同版本下，查询table_id的方式：

【mysql 5.x】select * from information_schema.innodb_sys_tables;

【mysql 8.x】select * from information_schema.innodb_tables;

INSERT对应的undo日志结构

TRX_UNDO_INSERT_REC类型的undo日志结构：

​

roll_pointer本质上就是一个指向记录对应的undo日志的指针。不同的内容放到了不同的页面中，其中：① 聚簇索引记录存放到类型为FIL_PAGE_INDEX的页面；② undo日志存放到类型为FIL_PAGE_UNDO_LOG的页面；

聚簇索引记录和undo日志的存放位置，如下图所示：

​

DELETE操作之垃圾链表

被删除的记录其实也会根据记录头信息中的next_record属性组成一个链表，只不过这个链表中的记录所占用的存储空间可以被重新利用，所以也称这个链表为垃圾链表。Page Header部分中有一个名为PAGE_FREE的属性，它指向由被删除记录组成的垃圾链表中的头节点。每删除一条记录，则该记录都会插入到垃圾链表的头节点处。

删除记录的两个步骤

第一步：delete mark阶段仅仅将记录的deleted_flag标识位设置为1，但是这条记录并没有加入到垃圾链表中。也就是说，这条记录即不是正常记录，也不是已删除记录。在删除语句所在的事务提交之前，被删除的记录一直都处于这种中间状态（其实主要是为了实现MVCC的功能才这样处理的）。

​

第二步：purge阶段当该删除语句所在的事务提交后，会有专门的线程来把该记录从正常记录链表中移除，并加入到垃圾链表中作为头节点

​

DELETE操作对应的undoLog结构

TRX_UNDO_DEL_MARK_REC类型的undo日志结构：

​

UPDATE操作对应的undoLog结构

TRX_UNDO_UPD_EXIST_REC类型的undo日志结构：

​

什么是ACID ？

Atomicity 原子性某个操作，要么全都执行完毕，要么全都回滚。

Consistency 一致性事务执行的结果应该符合数据库的约束条件和逻辑。

Isolation 隔离性在不同的业务处理过程中，事务保证了各自业务正在读、写的数据互相独立，不会彼此影响。

Durability 持久性现实中的状态转换映射到数据库中，意味着对数据所做的修改都应该在磁盘中保存。

事务的状态有哪些？

​

事务并发执行时数据一致性问题有哪些？

1、脏读；

        是指一个事务能读取其他事务未提交的数据。如果一个事务（小明）读取到了另一个未提交事务（小丽）修改过的数据，就意味着发生了脏读现象。

2、不可重复读；

        "同一事务先后读取同一条数据，但前后两次读到的数据是不一致的。(强调update 针对单行)" 一个事务在前后两次读取某个数据时，发现前后两次读到的数据是不一致的（数据发生了修改），这种现象叫做“不可重复读”。如果一个事务（小丽）修改了另一个未提交事务（小明）读取的数据，就意味着发生了不可重复读现象，或者叫模糊读FuzzyRead

3、幻像读；

        "同一事务先后读取一个范围的记录，但两次读取的纪录数不同。(强调insert或delete,范围查询)" 指的是在一个事务执行过程中，读取到了其他事务新插入数据，导致两次读取的结果不一致 。 一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读” 。如果一个事务（小明）先根据某些搜索条件（select ... where vip='是'）查询了一些记录，但是在该事务并未提交时，另一个事务（小丽）写入了一些符合上面搜索条件的记录（这里的写入可以值insert、delete、update操作。例如：insert into ... values('0003',700,'是')），就意味着发生了幻读现象。

4、丢失更新/脏写

        "撤销一个事务时，把其他事务已提交的更新数据覆盖" (事务A和B并发执行事物，A事务执行更新后，提交；B事务在A事务更新后，B事务结束前也做了对该行数据的更新操作，然后回滚，则两次更新操作都丢失了) "不可重复读和幻读的区别：可重复读是读到的是其他事务修改或者删除的数据，而幻读读到的是其它事务新插入的数据" 无论是脏读，不可重复读，还是幻读，它们都属于数据库的读一致性的问题，都是在一个事务里面前后两次读取出现了不一致的情况在多事务并发执行的环境下，一个事务修改了另一个未提交事务已经修改过的数据，从而导致数据不一致的问题。

SQL事务隔离级别

1、读未提交：

        "指一个事务还没提交时，它做的变更就能被其他事务看到"，会产生脏读、幻读、不可重复读。 所有事务都可以看到其他未提交事务的执行结果 比如同一时间有两个事物，一个正在修改，一个正在查询，查询的可以查看到正在修改的数据。若修改事物回滚，则查询的结果就是错误的。

2、读已提交：

        "指一个事务提交之后，它做的变更才能被其他事务看到"，会产生幻读、不可重复读。 一个事物只能看见其他已经提交的事物所做的改变 两个并发的事务，“事务1：小明消费”、“事务2：小红网上转账”，事务1事先读取了数据，事务2紧接了更新了数据，并提交了事务， 而事务1再次读取该数据时，数据已经发生了改变。

3、可重复读：

        "指一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的"，会产生幻读。 若同一事物修改数据，会产生两次读取数据结果不一致问题。 当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时会读取到包括刚插入的数据。 如小红查小明信用卡消费金额为50元，而小明此时正好买东西花了1000元，随后小红将小明当月的信用卡消费明细打印出来，却发现消费总额为1050元， 小红很诧异，以为是出现了幻觉。

4、串行化：

        "会对记录加上读写锁，在多个事务对这条记录进行读写操作时，如果发生了读写冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行" 这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决不读脏，可重复读，不可幻读。 简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争,并发性能最差,在分布式事务中可能会被用到 

        由于无论哪种隔离级别，都不允许脏写的情况发生，所以没有列入到表格中。

        数据库的事务隔离越严格，并发副作用就越小，但付出的代价也就越大， 因为事务隔离本质上就是使事务在一定程度上串行化，需要根据具体的业务需求来决定使用哪种隔离级别。

        事务不同隔离级别会产生3种数据不一致情况：

        1、脏读：读到其他事务未提交的数据；

        2、不可重复读：前后读取的数据不一致；

        3、幻读：前后读取的记录数量不一致。

注释：InnoDB在可重复读的级别就已经解决了幻读的问题，这也是InnoDB使用可重复读作为默认隔离级别的原因。 InnoDB 引擎的默认隔离级别是「可重复读」， InnoDB 通过next-key lock 锁(行锁和间隙锁的组合)来锁住记录之间的"间隙"和记录本身， 防止其他事务在这个记录之间插入新的记录，这样就避免了幻读现象。

四种隔离级别具体是如何实现的呢？

1、读未提交：因为可以读到未提交事务修改的数据，所以直接读取最新的数据就好了；

2、读已提交：通过 Read View 来实现的，隔离级别是在读取每个数据前都生成一个 Read View（MVCC）；

3、可重复读：通过 Read View 来实现的，隔离级别是启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View（MVCC）。

4、串行化： 通过加读写锁的方式来避免并行访问

        MVCC (Multi-Version Concurrency Control)多版本并发控制，利用记录的版本链和ReadView（一致性视图），来控制并发事务访问相同记录时的行为。

ReadView 一致性视图，用来判断版本链中的哪个版本是当前事务可见的。

版本链

在每次更新该记录后，都会将旧值放到一条undo日志中。随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一条链表，这个链表就称之为版本链。

​

ReadView包含的内容

ReadView也叫一致性视图，用来判断版本链中的哪个版本是当前事务可见的。ReadView包含4个比较重要的内容：

只有在对表中的记录进行改动时（即：insert、delete、update）才会为事务分配唯一的事务id，否则一个事务的事务id值都默认为0。

如何通过ReadView来判断记的某版本是否可见？

判断规则如下：

规则一：版本的事务 ID 与当前事务 ID 相同

如果RC.trx_id == RV.creator_trx_id，则表明当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。

规则二：版本的事务 ID 小于 Read View 中的最小事务 ID

规则二：版本的事务 ID 小于 Read View 中的最小事务 ID

如果RC.trx_id < RV.min_trx_id，则表明生成该版本的事务在当前事务生成ReadView之前已经提交了，所以该版本可以被当前事务访问。

规则三：版本的事务 ID 大于 Read View 中的最大事务 ID

如果RC.trx_id >= RV.max_trx_id，则表明生成该版本的事务在当前事务生成ReadView之后才开启，所以该版本不可以被当前事务访问。

规则四：版本的事务 ID 在 Read View 的活跃事务列表中

如果RC.trx_id in RV.m_ids，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果RC.trx_id not in RV.m_ids，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问（m_ids为空集合）。

如果某个版本的数据对当前事务不可见，那就顺着版本链找到下一个版本的数据，并继续执行上面的步骤来判断记录的可见性，以此类推，直到版本链中的最后一个版本。

Read View 生成时机

不同的事务隔离级别下，Read View 生成的时机有所不同。主要是因为不同隔离级别对数据一致性和并发性能的侧重点不同，通过调整 Read View 的生成时机来满足相应的要求。

READ COMMITTED和REPEATABLE READ隔离级别之间一个非常大的区别就是——它们生成ReadView的时机不同

READ COMMITTED——在一个事务中，每次读取数据前都生成一个ReadView。

REPEATABLE READ——在一个事务中，只在第一次读取数据时生成一个ReadView。

隔离级别及事务重要参数查询和设置

show variables like 'transaction_isolation';set session transaction isolation level read committed;set session transaction isolation level repeatable read;show variables like 'autocommit'; set autocommit=0;

并发事务问题

1.写-写

由于任何一种隔离级别都不允许脏写（写-写）的现象发生，所以，当多个未提交事务相继对一条记录进行改动的时候，就需要让它们排队执行。

这个排队的过程就是通过为该记录加锁来实现的。这个锁本质上是一个内存中的结构。

2.读-写/写-读

为了避免在“读-写”情况下避免脏读、不可重复读、幻读现象，有如下两种可选的解决方案：① 方案1：快照读 | 一致性读 | 一致性无锁读

读操作——MVCC；写操作——对记录进行加锁。

② 方案2：锁定读（S锁 | X锁）

读、写操作都采用加锁的方式

如果采用MVCC方式，读-写操作彼此并不冲突，性能更高

如果采用加锁方式，读-写操作彼此需要排队执行，从而影响性能；

所有普通的SELECT语句在READ COMMITTED或REPEATABLE READ隔离级别下都算是一致性读。所以一般来说，我们会选择采用MVCC方式来解决读-写操作并发执行的问题，但是在某些特殊的业务场景（如：银行业务，需要读取最新数据和数据准确性，对执行时间并无苛刻要求），这时我们才会选择读、写都加锁的方式。

下面几种重要的锁会持续更新

记录锁*