个人主页：C++忠实粉丝
欢迎 点赞👍 收藏✨ 留言✉ 加关注💓本文由 C++忠实粉丝 原创MySQL 深入理解隔离性
收录于专栏[MySQL]
本专栏旨在分享学习MySQL的一点学习笔记，欢迎大家在评论区交流讨论💌
由于之前在 MySQL 事务特性中，自认为还是没有搞明白，所以这里再次深入理解一下~
数据库并发的场景有三种：
1. 读-读：不存在任何问题，也不需要并发控制
2. 读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读
3. 写-写：有线程安全，可能会存在更新丢失问题，比如第一类更新丢失，第二类丢失等。
读 - 写
多版本控制（MVCC）是一种用来解决 读-写冲突 的无锁并发控制
为事务分配单向增长的事务 ID，为每个修改保存一个版本，版本与事务 ID 关联，读操作只读事务开始前的数据库的快照。所以 MVCC 可以为数据库解决以下问题
1. 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读的性能
2. 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题
理解 MVCC 需要知道三个前提知识：
1. 3个记录隐藏字段
2. undo 日志
3. Read View
3个记录隐藏列字段
DB_TRX_ID ： 6byte，最近修改（修改/插入）事务ID，记录创建这条记录/最后一次修改该记录的事务ID
DB_ROLL_PTR：7byte，回滚指针，指向这条记录的上一个版本（简单理解成，指向历史版本就行，这些数据一般在 undo log 中）
DB_ROW_ID：6type，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB 会自动以 DB_ROW_ID 产生一个聚簇索引
补充：实际还有一个删除 flag 隐藏字段，既记录被更新或删除并不代表真的删除，而是删除 flag 变了
假设测试表结构是：
上面描述的意思是：
| name | age | DB_TRX_ID(创建该记录的事务ID) | DB_ROW_ID(隐式主键) | DB_ROLL_PTR(回滚指针) |
|---|---|---|---|---|
| 张三 | 28 | null | 1 | null |
我们目前并不知道创建该记录的事务ID，隐式主键，我们就默认设置成null，第一条记录也没有其他版本，我们设置回回滚指针为 null。
undo日志
这里不细讲，但是有一件事情得说清楚，MySQL 将来是以服务进程得方式，在内存中运行。我们之前所讲的所有机制：索引，事务，隔离性，日志等，都是在内存中完成的，即在 MySQL 内部的相关缓冲区中，保存数据，完成各种判断操作。然后在合适的时候，将相关数据刷新到磁盘中。
所以，我们这里理解 undo log，简单理解成，就是 MySQL 中的一段内存缓冲区，用来保存日志数据的就行。
模拟 MVCC
现在有一个事务10（仅仅为了好区分），对 student 表中记录进行修改（update）：将 name（张三）改成 name（李四）。
事务10，因为要修改，所以要先给记录加行锁。
修改前，现将行记录拷贝到 undo log 中，所以，undo log 中就有了一行副本数据。（原理就是写时拷贝）
所以现在 MySQL 中有两行同样的记录。现在修改原始记录中的 name，改成 ‘李四’。并且修改原始记录的隐藏字段 DB_TRX_ID 为当前事务10的ID，我们默认从10开始，之后递增。而原始记录的回滚指针 DB_ROLL_PTR 列，里面写入 undo log 中副本数据的地址，从而指向副本记录，既表示我的上一个版本就是它。
事务10提交，释放锁。
备注：此时，最新的记录是 '李四' 那条记录。
现在又有一个事务11，对 student 表中记录进行修改（update） ：将 age(28) 改成 age(38).
1. 事务11，因为也要修改，所以要先给记录进行修改(update)：将 age(28) 改成 age(38)。
2. 修改前，现将改行记录拷贝到 undo log 中，所以，undo log 中就有了一行副本数据。此时，新的副本，我们采用头插方式，插入 undo log。
3. 现在修改原始记录中的 age，改成 38。并且修改原始记录的隐藏字段 DB_TRX_ID 为当前事务11的ID。而原始记录的回滚指针 DB_ROLL_PTR列，里面写入 undo log 中副本数据的地址，从而指向副本记录，即表示我的上一个版本就是它。
事务11提交，释放锁。
这样，我们就有了一个基于链表记录的历史版本链。所谓的回滚，无非就是用历史数据，覆盖当前数据。
上面的一个一个版本，我们可以称为一个一个的快照。
思考：
上面是以更新（`upadte`）主讲的,如果是`delete`呢？一样的，别忘了，删数据不是清空，而是设置flag 为删除即可。也可以形成版本。
如果是`insert`呢？因为`insert`是插入，也就是之前没有数据，那么`insert`也就没有历史版本。但是一般为了回滚操作，insert的数据也是要被放入undo log中，如果当前事务commit了，那么这个undo log 的历史insert记录就可以被清空了。
总结一下，也就是我们可以理解成，`update`和`delete`可以形成版本链，`insert`暂时不考虑。
那么`select`呢？
首先，`select`不会对数据做任何修改，所以，为`select`维护多版本，没有意义。不过，此时有个问题， 就是：
select读取，是读取最新的版本呢？还是读取历史版本？
当前读：读取最新的记录，就是当前读。增删改，都叫做当前读，select也有可能当前读，比如：select lock in share mode(共享锁), select for update （这个好理解，我们后面不讨论）
快照读：读取历史版本(一般而言)，就叫做快照读。(这个我们后面重点讨论)
我们可以看到，在多个事务同时删改查的时候，都是当前读，是要加锁的。那同时有select过来，如果也要读取最新版(当前读)，那么也就需要加锁，这就是串行化。 但如果是快照读，读取历史版本的话，是不受加锁限制的。也就是可以并行执行！换言之，提高了效率，即 MVCC的意义所在。
那么，是什么决定了，select是当前读，还是快照读呢？隔离级别！
那为什么要有隔离级别呢？ 事务都是原子的。所以，无论如何，事务总有先有后。
但是经过上面的操作我们发现，事务从begin->CURD->commit，是有一个阶段的。也就是事务有执行前，执 行中，执行后的阶段。但，不管怎么启动多个事务，总是有先有后的。
那么多个事务在执行中，CURD操作是会交织在一起的。那么，为了保证事务的“有先有后”，是不是应该让不同的事务看到它该看到的内容，这就是所谓的隔离性与隔离级别要解决的问题。
先来的事务，应不应该看到后来的事务所做的修改呢?
那么，如何保证，不同的事务，看到不同的内容呢？也就是如何实现隔离级别？
Read View
Read View 就是事务进行 快照读 操作的时候产生的 读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID(当每个事务开启时，都会被分配一个ID，这个ID是递增的，所以最新的事务，ID值越大)
Read View 在 MySQL 源码中就是一个类，本质是用来进行可见性判断的。即当我们某个事务执行快照读的时候，对该记录创建一个 Read View 读视图，把它比作条件，用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的 undo log 里面的某个版本的数据。
下面是 Read View 结构，这里进行了简化：
class ReadView
{
// 省略...
private:
/** 高水位，大于等于这个ID的事务均不可见*/
trx_id_t m_low_limit_id
/** 低水位：小于这个ID的事务均可见 */
trx_id_t m_up_limit_id;
/** 创建该 Read View 的事务ID*/
trx_id_t m_creator_trx_id;
/** 创建视图时的活跃事务id列表*/
ids_t m_ids;
/** 配合purge，标识该视图不需要小于m_low_limit_no的UNDO LOG，
* 如果其他视图也不需要，则可以删除小于m_low_limit_no的UNDO LOG*/
trx_id_t m_low_limit_no;
/** 标记视图是否被关闭*/
bool m_closed;
// 省略...
};m_ids; //一张列表，用来维护Read View生成时刻，系统正活跃的事务ID
up_limit_id; //记录m_ids列表中事务ID最小的ID(没有写错)
low_limit_id; //ReadView生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的
最大值+1(也没有写错)
creator_trx_id //创建该ReadView的事务ID我们在实际读取数据版本链的时候，是能读取到每一个版本对应的事务 ID 的，即：当前记录的 DB_TRX_ID。
那么，我们现在手里面有的东西就有，当前快照读的 Read View 和版本链中的某一个记录的 DB_TRX_ID。
所以现在的问题就是，当前快照读，应不应该读到当前版本记录。
如果查不到看到当前版本，接下来就是遍历下一个版本，直到符合条件，即可以看到。上面的 readview 是当你进行 select 的时候，会自动形成。
整体流程
假设当前有条记录：
事务操作：
事务4：修改name(张三)变成name(李四)
当事务2对某行数据执行了快照读，数据库为该行数据生成一个 Read View 读视图
//事务2的 Read View
m_ids; // 1,3
up_limit_id; // 1
low_limit_id; // 4 + 1 = 5，原因：ReadView生成时刻，系统尚未分配的下一个事务ID
creator_trx_id // 2此时版本链是：
只有事务4修改过该行记录，并在事务2执行快照读前，就提交了事务。
我们的事务2在快照读该行记录的时候，就会拿着该行记录的 DB_TRX_ID 去跟 up_limit_id，low_limit_id 和活跃事务 ID 列表(trx_list) 进行比较，判断当前事务2能看到该记录的版本。
//事务2的 Read View
m_ids; // 1,3
up_limit_id; // 1
low_limit_id; // 4 + 1 = 5，原因：ReadView生成时刻，系统尚未分配的下一个事务ID
creator_trx_id // 2
//事务4提交的记录对应的事务ID
DB_TRX_ID=4
//比较步骤
DB_TRX_ID（4）< up_limit_id（1） ? 不小于，下一步
DB_TRX_ID（4）>= low_limit_id(5) ? 不大于，下一步
m_ids.contains(DB_TRX_ID) ? 不包含，说明，事务4不在当前的活跃事务中。
//结论
故，事务4的更改，应该看到。
所以事务2能读到的最新数据记录是事务4所提交的版本，而事务4提交的版本也是全局角度上最新的版本RR 与 RC 的本质区别
当前读和快照在RR级别下的区别
用例1和用例2：唯一区别仅仅是表1的事务B在事务A修改age前快照读过一次age数据
而 表2 的事务B在事务A修改age前没有进行快照读。
结论：
事务中快照读的结果是非常依赖该事务首次出现快照读的地方，即某个事务中首次出现快照读，决定该事务后续快照结果的能力
delete 同样如此
RR 与 RC 的本质区别
正是 Read View 生成时机的不同，从而造成 RC，RR 级别下快照读的结果不同
在 RR 级别下的某个事务的对某条记录的第一次快照读会创建一个快照及 Read View，将当前系统活跃的其他事务记录起来
此后在调用快照读的时候，还是使用的是同一个 Read View，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个 Read View，所以对之后的修改不可见；
即 RR 级别下，快照读生成 Read View时，Read View 会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于 Read View 创建的事务所做的修改均是可见的。
而在 RC 级别下的，事务中，每次快照读都会生成并获取最新的 Read View；而在 RR 隔离级别下，则是同一个事务中的第一个快照读才会创建 Read View，之后的快照读获取的都是同一个 Read View。
正是 RC 每次快照读，都会形成 Read View，所以，RC 才会有不可重复读问题。