MySQL的隔离性实现之MVCC
前言
上篇文章曾经说过,针对于MySQL的读-写和写-读问题,有两种解决方案,一种是读写同时加锁,另一种则是本文要介绍的MVCC(多版本并发控制)。换句话说,MVCC是专门用来解决读-写和写-读问题的。
一、MVCC基础知识
1. MVCC基础知识
1.1 MVCC基本概念
- MVCC即Multiversion Consurrency Control,中文为多版本并发控制,通过数据行的多个版本管理来实现数据库的并发控制。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。换言之,就是为了查询一些正在被另一个事务更新的行,并且可以看到它们被更新之前的值,这样在做查询的时候就不用等待另一个事务释放锁。
1.2 快照读和当前读
-
快照读:快照读又叫一致性读,读取的是快照数据。不加锁的简单的SELECT都属于快照读,即不加锁的非阻塞读。
SELECT * FROM player WHERE ...
之所以出现快照读的情况,是基于提高并发性能的考虑,快照读的实现是基于MVCC,它在很多情况下,避免了加锁操作,降低了开销。既然是基于多版本,那么快照读可能读到的并不一定是数据的最新版本,而有可能是之前的历史版本。 快照读的前提是隔离级别不是串行级别,串行级别下的快照读会退化成当前读。
-
当前读:当前读读取的是记录的最新版本(最新数据,而不是历史版本的数据),读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。加锁的SELECT,或者对数据进行增删改都会进行当前读。
SELECT * FROM student LOCK IN SHARE MODE; # 共享锁 SELECT * FROM student FOR UPDATE; # 排他锁 INSERT INTO student values ... # 排他锁 DELETE FROM student WHERE ... # 排他锁 UPDATE student SET ... # 排他锁
3. 数据的隔离级别新解
实际上,由于我们使用了MVCC机制,在默认的隔离级别下(可重复读)也解决了幻读的问题,但此时的并不能说变成了串行化,因为串行化实际上使用了排他锁,读仍需要排队,而MVCC机制的读是不需要排队的,MVCC的性能更高。
2. MVCC优点
- MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能,用更好的方式去处理读-写冲突,做到即使有读写冲突时,也能做到不加锁,进行非阻塞并发读,而这个读指的就是快照读,而非当前读。当前读实际上是一种加锁的操作,是悲观锁的实现,而MVCC本质是采用乐观锁思想的一种方式。
二、MVCC的核心
1. 表中数据的隐藏字段和UodoLog版本链
对于使用 InnoDB 存储引擎的表来说,它的聚簇索引记录中都包含两个必要的隐藏列
trx_id
:每次一个事务对某条聚簇索引记录进行改动时,都会把该事务的事务id赋值给trx_id隐藏列,注意,只有在对表中的记录做改动时(执行INSERT、DELETE、UPDATE这些语句时)才会为事务分配事务id,否则在一个只读事务中的事务id值都默认为0。roll_pointer
:每次对某条聚簇索引记录进行改动时,都会把旧的版本写入到undo日志中,然后这个隐藏列就相当于一个指针,可以通过它来找到该记录修改前的信息。
注意:insert undo只在事务回滚时起作用,当事务提交后,该类型的undo日志就没用了,它占用的Undo Log Segment也会被系统回收(也就是该undo日志占用的Undo页面链表要么被重用,要么被释放)。
注意:能不能在两个事务中交叉更新同一条记录呢?不能,这就是一个事务修改了另一个未提交事务修改过的数据,脏写。InnoDB使用锁来保证不会有脏写情况的发生,也就是在第一个事务更新了某条记录后,就会给这条记录加锁,另一个事务再次更新时就需要等待第一个事务提交了 ,把锁释放之后才可以继续更新。
2. ReadView视图
2.1 基本概念
- 在MVCC机制中,多个事务对同一个行记录进行更新会产生多个历史快照,这些历史快照保存在Undo Log里。如果一个事务想要查询这个行记录,需要读取哪个版本的行记录呢?这时就需要用到ReadView了,它帮我们解决了行的可见性问题。ReadView就是事务在使用MVCC机制进行快照读操作时产生的读视图。当事务启动时,会生成数据库系统当前的一个快照,InnoDB 为每个事务构造了一个数组,用来记录并维护系统当前活跃事务的ID
(“活跃"指的就是,启动了但还没提交)
。
2.2 使用范围 — 限定在读已提交和可重复读
- 使用READ UNCOMMITTED隔离级别的事务,由于可以读到未提交事务修改过的记录,所以直接读取记录的最新版本就好了。
- 使用SERIALIZABLE隔离级别的事务,InnoDB规定使用加锁的方式来访问记录。
- 使用READ COMMITTED和REPEATABLE READ隔离级别的事务,都必须保证读到已经提交了的事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交,是不能直接读取最新版本的记录的,核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的,这是ReadView要解决的主要问题。
2.3 ReadView的组成
- creator_trx_id,创建这个Read View的事务ID。
- trx_ids,表示在生成ReadView时当前系统中活跃的读写事务的事务id列表(其中不包括本次的开启的读事务) 。
- up_limit_id,活跃的事务中最小的事务ID。
- low_limit_id,表示生成ReadView时系统中应该分配给下一个事务的id值。low_limit_id 是系统最大的事务id值,这里要注意是系统中的事务id,需要区别于正在活跃的事务ID。
2.4 ReadView的规则
- 如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同,意味着当前事务在访问它自己修改过的记录,所以该版本可以被当前事务访问。
- 如果被访问版本的trx_id属性值小于ReadView中的up_limit_id值,表明生成该版本的事务在当前事务生成ReadView前已经提交,所以该版本可以被当前事务访问。
- 如果被访问版本的trx_id属性值大于或等于ReadView中的low_limit_id值,表明生成该版本的事务在当前事务生成ReadView后才开启,所以该版本不可以被当前事务访问。
- 如果被访问版本的trx_id属性值在ReadView的up_limit_id和low_limit_id之间,那就需要判断一下trx_id属性值是不是在trx_ids列表中。
- 如果在,说明创建ReadView时生成该版本的事务还是活跃的,该版本不可以被访问。
- 如果不在,说明创建ReadView时生成该版本的事务已经被提交,该版本可以被访问。
2.5 ReadView的操作流程
- 首先获取正在查询的这条记录的事务的版本号,也就是事务ID。
- 获取ReadView。
- 查询得到的数据,然后与ReadView中的事务版本号进行比较。
- 如果不符合能够找到可以访问的数据,就需要从Undo Log中获取历史快照。
- 最后返回符合规则的数据。
2.6 在读已提交和可重复读下的区别
2.6.1 读已提交
在隔离级别为读已提交(Read Committed)时,一个事务中的每一次SELECT查询都会重新获取一次ReadView。注意,此时同样的查询语句都会重新获取一次ReadView,这时如果ReadView不同,就可能产生不可重复读或者幻读的情况。
2.6.2 可重复读
当隔离级别为可重复读的时候,一个事务只在第一次SELECT的时候会获取一次Read View,而后面所有的SELECT都会复用这个ReadView,就避免了不可重复读。