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


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
    nameage**DB_TRX_ID(**创建该记录的事务ID)**DB_ROW_ID(**隐式主键)**DB_ROLL_PTR(**回滚指针)
    张三28null1null

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记录就可以被清空了
  • 总结:可以理解成,updatedelete可以形成版本链,insert暂时不考虑
  • 那么select呢?
    • 首先,select不会对数据做任何修改,所以,为select维护多版本,没有意义
    • 不过,此时有个问题:select读取,是读取最新的版本呢?还是读取历史版本?
  • 当前读:读取最新的记录,就是当前读
    • 增删改,都叫做当前读,select也有可能当前读
      • 比如:select lock in share mode(共享锁),select for update
  • 快照读:读取历史版本(一般而言),就叫做快照读
  • 在多个事务同时删改查的时候,都是当前读,是要加锁的
    • 那同时有select过来,如果也要读取最新版(当前读),那么也就需要加锁,这就是串行化
  • 但如果是快照读,读取历史版本的话,是不受加锁限制的
    • 也就是可以并行执行!换言之,提高了效率,即MVCC的意义所在
  • 那么,是什么决定了select是当前读,还是快照读呢?
    • 隔离级别
  • 那为什么要有隔离级别呢?
    • 事务都是原子的,所以,无论如何,事务总有先有后
    • 但是经过上面的操作发现,事务从begin->CURD->commit,是有一个阶段的
      • 也就是事务有执行前,执行中,执行后的阶段
      • 但不管怎么启动多个事务,总是有先有后的。
    • 那么多个事务在执行中,CURD操作是会交织在一起的
      • 那么,为了保证事务的"有先有后",是不是应该让不同的事务看到它该看到的内容,这就是所谓的隔离性与隔离级别要解决的问题
  • 先来的事务,应不应该看到后来的事务所做的修改呢?
  • 那么,如何保证,不同的事务,看到不同的内容呢?也就是如何如何实现隔离级别?
  • 22
    点赞
  • 17
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

DieSnowK

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值