mysql高级

  • 前言
  • 1、什么是MVCC
  • 2、快照读和当前读
  • 2.1 快照读
  • 2.2 当前读
  • 3、回顾
  • 3.1 隔离级别
  • 3.2 隐藏字段、UndoLog版本链
  • 4、MVCC实现原理之ReadView
  • 4.1 什么是ReadView
  • 4.2 设计思想
  • 4.3 ReadView的规则
  • 4.4 MVCC整体操作流程
  • 5、总结
  • end...


前言

前面，我们在学习锁的时候就提到，MySQL解决脏读、不可重复读、幻读的两种方式，一种是读写都加锁，另一种是读用MVCC，写加锁，这样的好处是提交并发性能。本篇我们将去深入了解MVCC，探讨其中的原理。文章课程链接：MySQL数据库教程天花板，mysql安装到…

1、什么是MVCC

MVCC (Multiversion Concurrency Control) ，多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的 并发控制。这项技术使得在innoDB的事务隔离级别下执行 一致性读 操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。

MVCC 没有正式的标准，在不同的 DBMS 中 MVCC 的实现方式可能是不同的，也不是普遍使用的 (大家可以参考相关的 DBMS 文档)。这里讲解 InnoDB 中 MVCC 的实现机制 (MySQL其它的存储引擎并不支持它)。

2、快照读和当前读

MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到 不加锁，非阻塞并发读，而这个读指的就是 快照读，而非 当前读 。当前读实际上是一种加锁的操作，是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。

2.1 快照读

快照读又叫一致性读，读取的是快照数据，不加锁的简单的 SELECT 都属于快照读，即不加锁的非阻塞读；
之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于MVCC，它在很多情况下，避免了加锁操作，降低了开销。
既然是基于多版本，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。
快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。

2.2 当前读

当前读读取的是记录的最新版本（最新数据，而不是历史版本的数据），读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。加锁的 SELECT，或者对数据进行增删改都会进行当前读（获取最新数据在操作）。银行业务时大多为当前读。

3、回顾

3.1 隔离级别

在前面，我们讲到并发会带来4种问题（脏写、脏读…），有4个级别，如，读已提交可以解决脏读以上的问题，串行化能够解决所有问题，如图：

mysql mvc详解 mysql mvcc作用_java

在 MySQL 中，默认的隔离级别是可重复读，可以解决脏读和不可重复读的问题，如果仅从定义的角度来看，它并不能解决幻读问题。如果我们想要解决幻读问题，就需要采用串行化的方式，也就是将隔离级别提升到最高，但
这样一来就会大幅降低数据库的事务并发能力。
MVCC 可以不采用锁机制，而是通过乐观锁的方式来解决不可重复读和幻读问题！它可以在大多数情况下替代行级锁，降低系统的开销。

3.2 隐藏字段、UndoLog版本链

undo日志的版本链，对于使用 InnoDB 存储引擎的表来说，它的聚族索引记录中都包含两个必要的隐藏列：

  • trx_id：每次一个事务对某条聚族索引记录进行改动时，都会把该事务的 事务id 赋值给 trx_id 隐藏列
  • roll_pointer：每次对某条聚族索引记录进行改动时，都会把旧的版本写入到undo日志 中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

版本链如何形成，如图，我们对id为1的数据进行多次修改，依次是事务 8，事务10（修改两次），事务20（修改两次），事务10和20不会交叉修改，不然这样就造成了脏写，在事务10第一次写时，上锁，直到两次都修改完事务提交释放锁，事务20才开始操作：

mysql mvc详解 mysql mvcc作用_mysql_02


当事务10修改时，事务id变为10，回滚指针指向上次修改的信息

4、MVCC实现原理之ReadView

MVCC 的实现依赖于：隐藏字段、Undo Log、 Read View，其中，Read View起到的是控制（管理）的作用，简单理解就是我们该取哪个版本的数据

4.1 什么是ReadView

在MVCC机制中，多个事务对同一个行记录进行更新会产生多个历史快照，这些历史快照保存在 Undo Log 里。如果一个事务想要询这个行记录，需要读取哪个版本的行记录呢？这时就需要用到 ReadView 了，它帮我们解决了行的可见性问题。
ReadView 就是事务A在使用MVCC机制进行快照读操作时产生的读视图。当事务启动时，会生成数据库系统当前的一个快照，InnoDB 为每个事务构造了一个数组，用来记录并维护系统当前 活跃事务的ID（“活跃”指的就是，启动了但还没提交）。

4.2 设计思想

使用 READ UNCOMMITTED（读未提交）隔离级别的事务，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了
使用SERIALIZABLE（串行化）隔离级别的事务，InnoDB规定使用加锁的方式来访问记录
因此，它们俩都不需要使用MVCC
使用 READ COMMITTED 和 REPEATABLE READ 隔离级别的事务，都必须保证读到 已经提交了的 事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的，这是ReadView要解决的主要问题。

Readview中主要包含4个比较重要的内容：

  1. creator_trx_id ，创建这个 Read View 的事务ID（只有增删改才会为事务分配事务id，查询默认为0）。
  2. trx_ids，表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。
  3. up_limit_id，活跃的事务中最小的事务ID。
  4. low_limit_id，表示生成ReadView时系统中应该分配给下一个事务的id值，low_limit id 是系统最大的事务id值。

4.3 ReadView的规则

这个需要自己去理解下，为啥会存在大于或中间的trx_id，并发吗

  • 如果被访问版本的trx_id届性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
  • 如果被访问版本的trx_id属性值小于ReadView中的 up_limit_id 值，表明生成该版本的事务在当前事务生成
    ReadView前已经提交，所以该版本可以被当前事务访问。
  • 如果被访问版本的trx_id届性值大于或等于Readiew中的 low_limit_id 值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
  • 如果被访问版本的trx id属性值在ReadView的 up_limit_id和 low_limit_id之间，那就需要判断一下trx_id属性值是不是在 trx_ids 列表中。

如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问
如果不在，说明创建Readview时生成该版本的事务已经被提交，该版本可以被访问

4.4 MVCC整体操作流程

当查询一条记录的时候，系统如何通过MVCC找到它：

  1. 首先获取事务自己的版本号，也就是事务ID;
  2. 获取 ReadView;
  3. 查询得到的数据，然后与 ReadView 中的事务版本号进行比较
  4. 如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照
  5. 最后返回符合规则的数据。
    如果某个版本的数据对当前事务不可见的话（从最后一个开始），那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性，依此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对该事务完全不可见，查询结果就不包含该记录。

注意：在不同隔离级别下，ReadView的生成规则不同
在隔离级别为读已提交（Read Committed）时，一个事务中的每一次SELECT 查询都会重新获取一次 Read View。因为只需要保证读到的是提交的数据就行。

当隔离级别为可重复读的时候，这时事务只在第一次 SELECT 的时候会获取一次Read View，而后面所有的 SELECT 都会复用这个 Read View，因为不仅要考虑读到的是提交的数据，还要考虑读到的结果要一致（避免不可重复读和幻读）

5、总结

通过 MVCC 我们可以解决：

  1. 读写之间阻塞的问题 。通过 MVCC 可以让读写互相不阻塞，即读不阻塞写，写不阻塞读，这样就可以提升事务并发处理能力
  2. 降低了死锁的概率。这是因为 MVCC 采用了乐观锁的方式，读取数据时并不需要加锁，对于写操作，也只锁定必要的行。
  3. 解决快照读的问题。当我们查询数据库在某个时间点的快照时，只能看到这个时间点之前事务提交更新的结果，而不能看到这个时间点之后事务提交的更新结果。

end…

如果总结的还行，就点个赞呗 @_@ 如有错误，欢迎指正！