目录
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.示例
-
假设测试表结构是:
mysqlmysql> 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也有可能当前读
- 快照读:读取历史版本(一般而言),就叫做快照读
- 在多个事务同时删改查的时候,都是当前读,是要加锁的
- 那同时有select过来,如果也要读取最新版(当前读),那么也就需要加锁,这就是串行化
- 但如果是快照读,读取历史版本的话,是不受加锁限制的
- 也就是可以并行执行!换言之,提高了效率,即MVCC的意义所在
- 那么,是什么决定了select是当前读,还是快照读呢?
- 隔离级别
- 那为什么要有隔离级别呢?
- 事务都是原子的,所以,无论如何,事务总有先有后
- 但是经过上面的操作发现,事务从begin->CURD->commit,是有一个阶段的
- 也就是事务有执行前,执行中,执行后的阶段
- 但不管怎么启动多个事务,总是有先有后的。
- 那么多个事务在执行中,CURD操作是会交织在一起的
- 那么,为了保证事务的"有先有后",是不是应该让不同的事务看到它该看到的内容,这就是所谓的隔离性与隔离级别要解决的问题
- 先来的事务,应不应该看到后来的事务所做的修改呢?
- 那么,如何保证,不同的事务,看到不同的内容呢?也就是如何如何实现隔离级别?