【MySQL事务（下）（重点）】

---

再次理解MySQL事务

• 1.每个事务都有自己的事务ID，根据事务的大小，进行排队。
• 2.既然事务能排队，那就不能简单地认为事务就是一堆sql语句的集合，事务在语言看来，就是一个结构体对象/类对象。
• 3.mysql可能会面临处理多个事务的情况，事务也有自己的生命周期，所以mysql要对多个事务进行管理，那就需要先描述，再组织。

一、MVCC机制

数据库并发的场景有三种：

读-读 ：不存在任何问题，也不需要并发控制
读-写 ：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读（重点）
写-写 ：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失(后面补充)

重点在于第二类问题——读写。
要解决读写问题，就要学习MVCC机制，要学习MVCC机制，就要了解三个知识点：

• 3个记录隐藏字段
• undo日志
• Read View

3个记录隐藏列字段

• 1.DB_TRX_ID：占6字节，记录创建这个记录/最近修改这个记录的事务ID。
• 2.DB_ROLL_PTR：7字节，回滚指针，跟回滚有关的。指向这条记录的上一个版本。
• 3.DB_ROW——ID：6字节，这是一个隐藏的自增主键，如果表中没有创建主键，InnoDB会以该隐藏字段，产生一个聚簇索引。（就是建立一棵B+树，叶子节点与数据一起放的）

举例：

创建一个表，并插入一条数据：
create table if not exists student(
name varchar(11) not null,
age int not null);
mysql> insert into student (name, age) values (‘张三’, 28);

并且查看变量’autocommit’，这是一直开着的，所以，insert 这条插入sql语句，一定会被看成一个事务，自动提交了。

所以，看到的table，不仅仅是name，age两列，还有三个隐藏的字段：

因为insert语句也被看成了一个事务！

undo日志——由mysql维护的一段内存空间

这里理解undo log，简单理解成，就是 MySQL 中的一段内存缓冲区，用来保存日志数据的就行。

模拟MVCC的过程：

在上表的基础上，现在有一个事务10(仅仅为了好区分)，对student表中记录进行修改(update)：将name(张三)改成
name(李四)。

具体过程如下：
1.加锁
2.将修改前的整个记录，先拷贝一份到undo日志中，再将相关数据进行修改，结果如下：

回滚指针指向的是默认的上一条历史版本。
事务10的update语句完成后，就会释放锁。

现在又有一个事务11，对student表中记录进行修改(update)：将age(28)改成age(38)。

注意：这里修改，一定不会是修改历史版本的记录，因为历史版本记录是稳定的，持久的，改的是最新版本的事务。

1.加锁
2.将现存的事务先拷贝一份到undo日志中，再更新相关数据。
3.释放锁。

如上，就完成了数据的更新，同时形成了一份历史版本链。
这就是对历史事务进行管理的提现：先描述再组织，这个组织的过程就用了链表。

注意一些细节问题：

• 1.如果一个事务commit后，就无法回滚了。要知道，undo log只是一块内存缓冲区，会被写满，每次update/delete数据，都会保存一份历史版本，一旦commit后，就会把undo log的空间释放。
• 2.对于比较特殊的insert操作，因为是新插入的操作，那么在此之前不会形成版本链，但是为了回滚操作，insert的数据也会被拷贝到undo log中，所以一旦commit之后，undo log就会被释放，也就是insert也不会回滚了。

再次理解隔离性和隔离级别

正因为有了undo log这样的缓冲区来保存历史版本数据。
才有了读写并发访问事务，不需要加锁。因为读的是历史版本事务，写的是最新数据，读写的版本位置不同就不需要加锁。所以就是隔离性，针对隔离级别，就有RU，RC，RR，串行化等几种隔离级别，本质上就是是否允许同时读写历史版本的不同位置。

那么，如何保证，不同的事务，看到不同的内容呢？也就是如何如何实现隔离级别？

Read View 理论部分

现在的问题就是，当前快照读，应不应该读到当前版本记录，也就是应不应该读到历史版本链的事务。

Read View就是一个视图，在MySQL源码中，这是一个类，当我们查看历史版本时，就会生成这个Read View。具体只需要记住该类的四个成员即可：

m_ids;      //一张列表，用来维护Read View生成时刻，系统正活跃的事务ID
up_limit_id;   //记录m_ids列表中事务ID最小的ID(没有写错)
low_limit_id;   //ReadView生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的最大值+1(也没有写错，注意不是视图里面的最大事务ID+1)
creator_trx_id  //创建该ReadView的事务ID

注意：不是创建事务的时候，就形成这个Read View类，而是该事务已经存在的前提下，该事务第一次进行快照读（查看历史版本）的时候，就会形成这个Read View类。

所以，在该视图第一次查看事务时，会产生一个视图，这个视图就能看到当前sql系统正在活跃的事务。

具体如下图：
注意：事务ID是不断递增的，事务ID越小，说明该事务创建的越早。

• 1.首先解析中间的事务，在快照时，当前系统正在活跃的事务，也就是已经begin但未commit的事务。
• 2.已经提交的事务：在当前事务第一次进行快照读产生的Read View视图之前，已经commit的事务。
• 3.快照后来的新事务：这些事务是在进行快照都之后，才开始begin活跃的事务。
• 由于是已经形成Read View视图之后，才开始活跃的事务，所以在Read View列表中看不到。

解析这部分的意思：

• 1.creator_trx_id就是创建该视图的事务ID，当该事务ID(creator_trx_id) == 版本链中的某个事务ID(DB_TRX_ID)时，说明我要看的事务ID，就是我本身。
• 2.DB_TRX_ID < up_limit_id，说明我要查询的历史事务ID，小于当前我这个事务创建出来的视图ID（Read View），说明该事务是已经commit的，我应该要看到。

解析这部分的意思：
说明我当前要查询的事务ID，比我这个视图里面能看到的最大事务ID还要大，说明在我创建这个视图Read View的时候，你那个事务还没出生呢，或者你在我创建视图后才到来的。所以我不应该能看到你。

解析这部分的意思：
快照到的事务不一定连续。
如果要查询的事务ID不在Read View视图列表中，说明该事务已经提交，那就可以看到。
如果要查询的事务ID在Read View视图列表中，说明该事务同样是活跃事务还没commit，那么它的增删查改就不应该看到。

上面所提到的应不应该看到，指的是，应不应该出现在Read View视图里，这就像，假如我是大二学生，我应该要看到大四毕业学长的工作情况，但是当我大四的时候，我不可能也不应该看到大一的工作情况。

源码策略：

RR 和 RC 的本质区别

正是Read View生成时机的不同，从而造成RC,RR级别下快照读的结果的不同
在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View, 将当前系统活跃的其他事务记录起来此后在调用快照读的时候，还是使用的是同一个Read View，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个Read View，所以对之后的修改不可见；

即RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见。

而在RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因。

总之在RC隔离级别下，是每个快照读都会生成并获取最新的Read View；而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。正是RC每次快照读，都会形成Read View，所以，RC才会有不可重复读问题。

简单说：RR和RC，RR：不更新Read View视图。
RC，每次进行快照读都会更新Read View视图。