0.铺垫

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

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> 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

3.undo日志

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

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