• 前言
  • 共享锁和排它锁
  • 什么是当前读和快照读？
    • 当前读
    • 快照读
• MVCC
  • Read View
    • 流程
    • RR、RC生成Read View的时机
    • 总结

前言

MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。
--摘自 百度百科

MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。

共享锁和排它锁

• 共享锁（S锁）

  用于不更改或不更新数据的操作（只读操作），例如：SELECT 语句。

  如果事务 T 仅对数据 A 进行读取，那么会对数据 A 加上共享锁，之后则其他事务如果要读取数据 A 的话可以对其继续加共享锁，但是不能加排他锁（也就是无法修改数据）。获准共享锁的事务只能读数据，不能修改数据。

• 排他锁（X锁）

  用于数据修改操作，例如：INSERT、UPDATE 或 DELETE 语句。确保不会同时同一资源进行多重更新。

  如果事务 T 对数据 A 要进行修改，则需要对其添加排它锁，加上排他锁后，则其他事务不能再对 A 加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。

什么是当前读和快照读？

当前读

当前读：每次读取的都是数据库记录的最新版本，会对当前读取的数据进行加锁，防止其他事务修改数据，是悲观锁的一种操作。

像select xx from t_xx lock in share mode(共享锁)、select for update、update、insert、delete(排他锁)这些操作都是一种当前读。

因为，它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，因此，会对读取的记录进行加锁。

以下几种情况都是当前读：

• select 语句加锁

  # 共享锁
  select name from t_user where id = 1 lock in share mode;
  # 排他锁
  select name from t_user where id = 1 for update;
  

• update、insert、delete 语句

  # 排他锁
  update t_user set a = a + 1 where id = 1;
  

快照读

快照读：读写不冲突，每次读取的都是快照数据。

像不加锁的select操作就是快照读，即不加锁的非阻塞读。快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。

之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC，可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销。

因为它是基于多版本实现，因此，快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本，简而言之，MVCC 就是为了实现读-写冲突不加锁，而这个读指的就是快照读。

以下几种情况都是快照读：

• 在RR隔离级别下，不加锁的select语句：

  # select 语句
  select name from t_user where id = 1;
  

注意：

• 隔离级别为 Repeatable Read 时：有可能读取的不是最新的数据；
• 隔离级别为 Read Committed 时：快照读和当前读读取的数据是一样的，都是最新的。

MVCC

多版本并发控制（multiversion concurrency control，MVCC）是一种用来解决读-写冲突的无锁并发控制技术。它在RC和RR隔离级别下，为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。

所以，MVCC可以为数据库解决以下问题在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题。

解决问题如下：

• 并发读-写时：可以做到读操作不阻塞写操作，同时写操作也不会阻塞读操作。

• 解决脏读、幻读、不可重复读等事务隔离问题，但不能解决写-写更新丢失问题。因此需要下面提高并发性能的组合：

  • MVCC + 悲观锁：MVCC解决读写冲突，悲观锁解决写写冲突
  • MVCC + 乐观锁：MVCC解决读写冲突，乐观锁解决写写冲突

InnoDB引擎每行除了包含我们的定义的字段外，还会额外包含三个隐式字段：DB_TRX_ID 、DB_ROLL_PTR 、DB_ROW_ID 。

官方文档的原文如下：

Internally, InnoDB adds three fields to each row stored in the database:

• A 6-byte DB_TRX_ID field indicates the transaction identifier for the last transaction that inserted or updated the row. Also, a deletion is treated internally as an update where a special bit in the row is set to mark it as deleted.

• A 7-byte DB_ROLL_PTR field called the roll pointer. The roll pointer points to an undo log record written to the rollback segment. If the row was updated, the undo log record contains the information necessary to rebuild the content of the row before it was updated.

• A 6-byte DB_ROW_ID field contains a row ID that increases monotonically as new rows are inserted. If InnoDB generates a clustered index automatically, the index contains row ID values. Otherwise, the DB_ROW_ID column does not appear in any index.

以下面的例子为例：

Read View

Read View 就是事务进行快照读操作的时候生产的读视图，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的 ID (当每个事务开启时，都会被分配一个 ID , 这个 ID 是递增的，所以最新的事务，ID 值越大)。

Read View 主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个 Read View 读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，即可能是当前最新的数据，也有可能是该行记录的 undo log 里面的某个版本的数据。

对于使用 read-committed 和 repeatable-read 隔离级别的事务来说，都必须保证读到已经提交了的事务修改过的记录，也就是说假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的。

我们可以把Read View简单的理解成有三个全局属性：

• trx_list：未提交事务ID列表，用来维护Read View生成时刻系统正活跃的事务ID；
• up_limit_id：记录trx_list列表中事务ID最小的ID；
• low_limit_id：Read View生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的最大值+1。

流程

Read Veiw的生成流程如下：

以下面的例子，来说明：

RR、RC生成Read View的时机

RR、RC生成Read View的时机：

• RC隔离级别下，每个快照读都会生成并获取最新的Read View，因此可能出现在同一个事务中两次查询的结果不一致的情况；
• RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View，之后的快照读获取的都是同一个Read View，之后的查询就不会重复生成了，所以同一一个事务的查询结果每次都是一样的。

总结

参考：

• 15.3 InnoDB Multi-Versioning
• https://www.51cto.com/article/680143.html
• https://pdai.tech/md/db/sql-mysql/sql-mysql-mvcc.html
• https://www.cnblogs.com/michael9/p/12294380.html#_label4_0
• https://xiaolincoding.com/mysql/lock/mysql_lock.html