[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 复制代码
    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记录就可以被清空了
  • **总结:**可以理解成,updatedelete可以形成版本链,insert暂时不考虑
  • 那么select呢?
    • 首先,select不会对数据做任何修改,所以,为select维护多版本,没有意义
    • 不过,此时有个问题:select读取,是读取最新的版本呢?还是读取历史版本?
  • 当前读:读取最新的记录 ,就是当前读
    • 增删改,都叫做当前读,select也有可能当前读
      • 比如:select lock in share mode(共享锁),select for update
  • 快照读:读取历史版本(一般而言),就叫做快照读
  • 在多个事务同时删改查的时候,都是当前读,是要加锁的
    • 那同时有select过来,如果也要读取最新版(当前读),那么也就需要加锁,这就是串行化
  • 但如果是快照读,读取历史版本的话,是不受加锁限制的
    • 也就是可以并行执行!换言之,提高了效率,即MVCC的意义所在
  • 那么,是什么决定了select是当前读,还是快照读呢?
    • 隔离级别
  • 那为什么要有隔离级别呢?
    • 事务都是原子的,所以,无论如何,事务总有先有后
    • 但是经过上面的操作发现,事务从begin->CURD->commit,是有一个阶段的
      • 也就是事务有执行前,执行中,执行后的阶段
      • 但不管怎么启动多个事务,总是有先有后的。
    • 那么多个事务在执行中,CURD操作是会交织在一起的
      • 那么,为了保证事务的"有先有后",是不是应该让不同的事务看到它该看到的内容,这就是所谓的隔离性与隔离级别要解决的问题
  • 先来的事务,应不应该看到后来的事务所做的修改呢?
  • 那么,如何保证,不同的事务,看到不同的内容呢?也就是如何如何实现隔离级别?
相关推荐
islandzzzz41 分钟前
三表查询SQL怎么写?----小白初学+案例引入
数据库
卡布奇诺-海晨1 小时前
MySQL的MVCC机制
数据库·mysql
hao_wujing2 小时前
攻击模型的恶意行为检测
网络·数据库·php
秃头摸鱼侠3 小时前
MySQL查询语句(续)
数据库·mysql
MuYiLuck3 小时前
【redis实战篇】第八天
数据库·redis·缓存
睡觉待开机3 小时前
6. MySQL基本查询
数据库·mysql
大熊猫侯佩4 小时前
由一个 SwiftData “诡异”运行时崩溃而引发的钩深索隐(三)
数据库·swiftui·swift
大熊猫侯佩4 小时前
由一个 SwiftData “诡异”运行时崩溃而引发的钩深索隐(二)
数据库·swiftui·swift
大熊猫侯佩4 小时前
用异步序列优雅的监听 SwiftData 2.0 中历史追踪记录(History Trace)的变化
数据库·swiftui·swift
大熊猫侯佩4 小时前
由一个 SwiftData “诡异”运行时崩溃而引发的钩深索隐(一)
数据库·swiftui·swift