[MySQL][深入理解隔离性][上][MVCC]详细讲解

0.铺垫

在RR级别的时候，多个事务的update，多个事务的insert，多个事务的delete，是否会有加锁现象？
- 现象结果是，update，insert，delete之间是会有加锁现象的
- 但是select和这些操作是不冲突的
- 这就是通过读写锁(锁有行锁或者表锁)+MVCC完成隔离性
数据库并发的场景有三种
- 读-读：不存在任何问题，也不需要并发控制
  - 不讨论
- 读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读
- 写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失
  - 现阶段，直接理解成都是当前读，不做深究

MVCC_17">1.初识MVCC

多版本并发控制(MVCC)是一种用来解决 读-写冲突 的无锁并发控制
为事务分配单向增长的事务ID，为每个修改保存一个版本，版本与事务ID关联，读操作只读该事务开始前的数据库的快照
所以 MVCC 可以为数据库解决以下问题
- 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能
- 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题
理解 MVCC 需要知道三个前提知识
- 3个记录隐藏字段
- undo 日志
- Read View

2.三个记录隐藏列字段

1.是什么？

DB_TRX_ID：6 byte，最近(修改/插入)事务ID，记录创建这条记录/最后一次修改该记录的事务ID
DB_ROLL_PTR：7 byte，回滚指针，指向这条记录的上一个版本(简单理解成，指向历史版本就行，这些数据一般在 undo log 中)
DB_ROW_ID：6 byte，隐含的自增ID(隐藏主键)，如果数据表没有主键， InnoDB 会自动以 DB_ROW_ID 产生一个聚簇索引
补充：实际还有一个删除flag隐藏字段，即：记录被更新或删除并不代表真的删除，而是删除flag变了

2.示例

假设测试表结构是：

mysql">mysql> create table if not exists student(name varchar(11) not null,age int not null
);mysql> insert into student (name, age) values ('张三', 28);
mysql> select * from student;
+--------+-----+
| name   | age |
+--------+-----+
| 张三   | 28  |
+--------+-----+

上面描述的意思是：
- 目前并不知道创建该记录的事务ID，隐式主键，就默认设置成null，1
- 第一条记录也没有其他版本，设置回滚指针为null
name age **DB_TRX_ID(**创建该记录的事务ID) **DB_ROW_ID(**隐式主键) **DB_ROLL_PTR(**回滚指针)
张三 28 null 1 null

name	age	DB_TRX_ID(创建该记录的事务ID)	DB_ROW_ID(隐式主键)	DB_ROLL_PTR(回滚指针)
张三	28	null	1	null

3.undo日志

这里不想细讲，但是有一件事情得说清楚， MySQL 将来是以服务进程的方式在内存中运行
- 之前所讲的所有机制：索引，事务，隔离性，日志等，都是在内存中完成的
- 即：在 MySQL 内部的相关缓冲区中，保存相关数据，完成各种判断操作，然后在合适的时候，将相关数据刷新到磁盘当中的
所以，这里理解undo log，简单理解成，就是 MySQL 中的一段内存缓冲区，用来保存日志数据的就行

MVCC_71">4.模拟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提交，释放锁
TIPS：此时，最新的记录是’李四’那条记录
现在又有一个事务11，对student表中记录进行修改(update)：将age(28)改成age(38)
- 事务11因为也要修改，所以要先给该记录加行锁
- 修改前，先将该行记录拷贝到undo log中，所以，undo log中就又有了一行副本数据
  - 此时，新的副本，采用头插方式，插入undo log
- 现在修改原始记录中的age，改成38，并且修改原始记录的隐藏字段 DB_TRX_ID 为当前事务11 的ID
- 而原始记录的回滚指针 DB_ROLL_PTR 列，里面写入undo log中副本数据的地址，从而指向副本记录
  - 即：表示我的上一个版本就是它
- 事务11提交，释放锁
这样，就有了一个基于链表记录的历史版本链
- 所谓的回滚，无非就是用历史数据，覆盖当前数据
- 上面的一个一个版本，可以称之为一个一个的快照

5.思考

上面是以更新(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操作是会交织在一起的
  - 那么，为了保证事务的"有先有后"，是不是应该让不同的事务看到它该看到的内容，这就是所谓的隔离性与隔离级别要解决的问题
先来的事务，应不应该看到后来的事务所做的修改呢?
那么，如何保证，不同的事务，看到不同的内容呢？也就是如何如何实现隔离级别？