Mysql原理篇之MVCC原理--01

Posted 热爱编程的大忽悠

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Mysql原理篇之MVCC原理--01相关的知识，希望对你有一定的参考价值。

mysql原理篇之MVCC原理--01

一、MVCC定义

MVCC（Mutil Version Concurrency Control）多版本并发控制，是一种并发控制的方法（而非具体实现），一般在数据库管理系统中，实现对数据库的并发访问。

上面的解释比较抽象，下面来一点一点分析。

1、并发事务可能产生的问题

  • 当一个事务访问数据库的数据时，无论读、写，都不会产生并发问题。

  • 当两个事务同时访问数据库中的相同数据时，可能有几种情况：

    • 读：两个事务都查询数据。当两个事务对相同数据全部是读操作时，不会产生任何并发问题。
    • 读+写：一个事务查询数据，一个事务修改数据。当两个事务对相同数据有读有写时，可能会产生脏读、不可重复度、幻读的问题（但发生脏读、不可重复度、幻读就并不一定表示有问题，具体还是要看场景，有些业务场景发生不可重复度是不允许的，但有些业务场景可能发生脏读也没啥大碍）。
    • 写：两个事务都修改数据，当两个事务对相同数据全部是写操作时，可能产生数据丢失（回滚丢失、覆盖丢失）等问题。

    多个事务同时访问数据库中相同的数据，也是一样的，可能存在【读】、【读+写】、【写】这三种情况。

那如何解决上面的问题呢？

  • 并发事务对数据的读操作不会产生并发问题，所以不用解决；
  • 并发事务对数据的读+写，常规操作一般会对要操作的数据加锁来解决并发读+写可能产生的问题，MySQL的InnoDB实现了MVCC来更好地处理读写冲突，可以做到即使存在并发读写，也可以不用加锁，实现"非阻塞并发读"。
  • 并发事务对数据的写操作，只能通过加锁(乐观锁/悲观锁)来解决。

到了这里，我们脑子里需要有这么个印象：MySQL实现的MVCC，主要是用于在并发读写的情况下，保证 “读” 数据时无需加锁也可以读取到数据的某一个版本的快照，好处是可以避免加锁，降低开销，解决了读写冲突，增大了数据库的并发性能。

2、当前读和快照读

在进一步了解MySQL中实现MVCC的细节之前，还需要了解两个定义：

  • 当前读：读取的数据是最新版本，读取数据时还要保证其他并发事务不会修改当前的数据，当前读会对读取的记录加锁。比如：select …… lock in share mode（共享锁）、select …… for update | update | insert | delete（排他锁）
  • 快照读：每一次修改数据，都会在 undo log 中存有快照记录，这里的快照，就是读取undo log中的某一版本的快照。这种方式的优点是可以不用加锁就可以读取到数据，缺点是读取到的数据可能不是最新的版本。一般的查询都是快照读，比如：select * from t_user where id=1; 在MVCC中的查询都是快照度。

二、MVCC实现、原理

MySQL中MVCC主要是通过行记录中的隐藏字段（隐藏主键 row_id、事务ID trx_id、回滚指针 roll_pointer）、undo log（版本链）、ReadView（一致性读视图）来实现的。

1、隐藏字段

MySQL中，在每一行记录中除了自定义的字段，还有一些隐藏字段：

row_id：当数据库表没定义主键时，InnoDB会以row_id为主键生成一个聚集索引。

trx_id：事务ID记录了新增/最近修改这条记录的事务id，事务id是自增的。

roll_pointer：回滚指针指向当前记录的上一个版本（在 undo log 中）。

2、版本链

简单提下 redo log 和 undo log。在修改数据的时候，会向 redo log 中记录修改的页内容（为了在数据库宕机重启后恢复对数据库的操作），也会向 undo log 记录数据原来的快照（用于回滚事务）。undo log有两个作用，除了用于回滚事务，还用于实现MVCC。

用一个简单的例子来画一下MVCC中用到的undo log版本链的逻辑图：

当事务100（trx_id=100）执行了 insert into t_user values(1,'张三',20); 之后：

当事务102（trx_id=102）执行了 update t_user set name='李四' where id=1; 之后：

当事务103（trx_id=103）执行了 update t_user set name='王五' where id=1; 之后：

3、ReadView

在上面的例子中，多个事务对 id=1 的数据修改后，这行记录除了最新的数据，在 undo log 中还有多个版本的快照。那其他事务查询时能查到最新版本的数据吗？如果不能，能读到哪个版本的快照呢？这就要由ReadView来决定了。

ReadView 就是MVCC在对数据进行快照读时，会产生的一个”读视图“（翻译过来就是ReadView~哈哈哈）。

ReadView中有4个比较重要的变量（具体这几个变量名是啥我也不知道，不过不要在意这些细节，这里就随便定义一下……）：

  • m_ids：活跃事务id列表，当前系统中所有活跃的（也就是没提交的）事务的事务id列表。
  • min_trx_id：m_ids 中最小的事务id。
  • max_trx_id：生成 ReadView 时，系统应该分配给下一个事务的id（注意不是 m_ids 中最大的事务id），也就是m_ids 中的最大事务id + 1
  • creator_trx_id：生成该 ReadView 的事务的事务id。

读视图是在进行数据读取时,才会进行创建

某个事务进行快照读时可以读到哪个版本的数据，ReadView 有一套算法：

（1）当【版本链中记录的 trx_id 等于当前事务id（trx_id = creator_trx_id）】时，说明版本链中的这个版本是当前事务修改的，所以该快照记录对当前事务可见。

（2）当【版本链中记录的 trx_id 小于活跃事务的最小id（trx_id < min_trx_id）】时，说明版本链中的这条记录已经提交了，所以该快照记录对当前事务可见。

（3）当【版本链中记录的 trx_id 大于下一个要分配的事务id（trx_id > max_trx_id）】时,说明版本链中这条记录是晚于当前ReadView创建的事务,该快照记录对当前事务不可见。

（4）当【版本链中记录的 trx_id 大于等于最小活跃事务id】且【版本链中记录的trx_id小于下一个要分配的事务id】（min_trx_id<= trx_id < max_trx_id）时，如果版本链中记录的 trx_id 在活跃事务id列表 m_ids 中，说明生成 ReadView 时，修改记录的事务还没提交，所以该快照记录对当前事务不可见；否则该快照记录对当前事务可见。

记录的快照是在对记录进行修改的时候才会产生的。

当事务对 id=1 的记录进行快照读时select * from t_user where id=1，在版本链的快照中，从最新的一条记录开始，依次判断这4个条件，直到某一版本的快照对当前事务可见，否则继续比较上一个版本的记录。

MVCC主要是用来解决RU隔离级别下的脏读和RC隔离级别下的不可重复读的问题，所以MVCC只在RC（解决脏读）和RR（解决不可重复读）隔离级别下生效，也就是MySQL只会在RC和RR隔离级别下的快照读时才会生成ReadView。区别就是，在RC隔离级别下，每一次快照读都会生成一个最新的ReadView；在RR隔离级别下，只有事务中第一次快照读会生成ReadView，之后的快照读都使用第一次生成的ReadView。

还是有点抽象？那就手动来亲自验证一下，之后就会清晰很多。（如果想要真正理解上面的算法，建议最好找个例子，亲自验证一下）

三、手动验证MVCC的原理

还是用上面的例子来说。

前提条件：事务100（trx_id=100）向表中插入了一条id=1的数据： insert into t_user values(1,'张三',20); 并提交了事务。

之后又有3个事务（事务101、事务102、事务103）来对这条数据进行读写操作：

时间顺序事务101事务 102事务 103
t1begin
t2select * from t_user where id=1;
t3begin
t4select * from t_user where id=1;
t5begin
t6select * from t_user where id=1;
t7update t_user set name=‘李四’ where id=1;
t8select * from t_user where id=1;
t9select * from t_user where id=1;
t10commit
t11select * from t_user where id=1;
t12update t_user set name=‘王五’ where id=1;
t13commit
t14select * from t_user where id=1;

在时间点 t1 ~ t6 时，整个版本链中只有一个快照，trx_id 为 100：

在时间点 t7 ~ t11 时，整个版本链中有两个快照，trx_id 为 102、100：

在时间点 t11 ~ t14 时，整个版本链中有三个快照，trx_id 为 103、102、100：

1、事务隔离级别为RC（读已提交隔）：

当前事务隔离级别为RC（读已提交隔）时，每个事务每次查询对应生成的ReadView是这样的，跟着这张图来梳理一下：

  • 在时间点t2，事务101查询时生成的ReadView内容为：

    trx_list: 101
min_trx_id:101
max_trx_id:102
creator_trx_id:101

    当前时间点，版本链中只有一个快照(trx_id=100)，因为 trx_id(100)< min_trx_id(101)，符合算法的第（2）条规则，所以trx_id=100的这个快照对当前事务可见。

  • 在时间点t4，事务102查询时生成的ReadView内容为：

    trx_list: 101,102
min_trx_id:101
max_trx_id:103
creator_trx_id:102
复制代码

    当前时间点，版本链中只有一个快照(trx_id=100)，因为 trx_id(100)< min_trx_id(101)，符合算法的第（2）条规则，所以trx_id=100的这个快照对当前事务可见。

  • 在时间点t6，事务103查询时生成的ReadView内容为：

    trx_list: 101,102,103
min_trx_id:101
max_trx_id:104
creator_trx_id:103

    当前时间点，版本链中只有一个快照(trx_id=100)，因为 trx_id(100)< min_trx_id(101)，符合算法的第（2）条规则，所以trx_id=100的这个快照对当前事务可见。

  • 在时间点t8，事务101查询时生成的ReadView内容为：

    trx_list: 101,102,103
min_trx_id:101
max_trx_id:104
creator_trx_id:101

    当前时间点，版本链中有两个快照(trx_id=102 -> trx_id=100)，从版本链中的快照中，从最新的开始，依次判断：

    对于trx_id=102的快照，min_trx_id(101) <= trx_id(102) < max_trx_id(104) ，且trx_id(102) 在 trx_list(101,102,103) 中，说明当前事务生成ReadView时，修改该记录的事务仍然是活跃事务（还未提交），根据算法的第(4)条规则，trx_id=102的快照对当前事务不可见。这也就验证了在RC隔离级别下，事务102修改但未提交的数据对于事务101应该不可见。

    对于trx_id=100的快照，因为 trx_id(100)< min_trx_id(101)，符合算法的第（2）条规则，所以trx_id=100的这个快照对当前事务可见。

  • 在时间点t9，事务102查询时生成的ReadView内容为：

    trx_list: 101,102,103
min_trx_id:101
max_trx_id:104
creator_trx_id:102

    当前时间点，版本链中有两个快照(trx_id=102 -> trx_id=100)，从版本链中的快照中，从最新的开始，依次判断：

    对于trx_id=102的快照，因为 trx_id(102) = creator_trx_id(102)，符合算法的第（1）条规则，所以trx_id=102的这个快照对当前事务可见。

  • 在时间点t11，事务103查询时生成的ReadView内容为：

    trx_list: 101,103
min_trx_id:101
max_trx_id:104
creator_trx_id:103

    当前时间点，版本链中有两个快照(trx_id=102 -> trx_id=100)，从版本链中的快照中，从最新的开始，依次判断：

    对于trx_id=102的快照，min_trx_id(101) <= trx_id(102) < max_trx_id(104) ，且trx_id(102) 不在 trx_list(101,103) 中，说明当前事务生成ReadView时，修改该记录的事务不是活跃事务（已经提交），根据算法的第(4)条规则，trx_id=102的快照对当前事务可见。这也就验证了在RC隔离级别下，事务102修改且提交的数据对于事务103是可见的。

  • 在时间点t14，事务101查询时生成的ReadView内容为：

    trx_list: 101
min_trx_id:101
max_trx_id:104
creator_trx_id:101

    当前时间点，版本链中有三个快照(trx_id=103 -> trx_id=102 -> trx_id=100)，从版本链中的快照中，从最新的开始，依次判断：

    对于trx_id=103的快照，min_trx_id(101) <= trx_id(103) < max_trx_id(104) ，且trx_id(103) 不在 trx_list(101) 中，说明当前事务生成ReadView时，修改该记录的事务不是活跃事务（已经提交），根据算法的第(4)条规则，trx_id=103的快照对当前事务可见。这也就验证了在RC隔离级别下，事务103修改且提交的数据对于事务101是可见的。

2、事务隔离级别为RR（可重复读）：

当前事务隔离级别为RR（可重复读）时，每个事务每次查询对应生成的ReadView是这样的，跟着这张图来梳理一下：

上面说过，在RC隔离级别下，每一次快照读都会生成一个最新的ReadView；在RR隔离级别下，只有事务中第一次快照读会生成ReadView，之后的快照读都使用第一次生成的ReadView。

所以，事务101在 t8、t14 时刻查询时，使用的 ReadView 跟 t2 时刻一样；事务102在t9时刻查询时使用的ReadView 跟 t4 时刻一样；事务103在 t11 时刻查询时使用的ReadView 跟 t6 时刻一样。

文章到这里就结束了，有心的同学可以跟着上面【事务隔离级别为RC】时的步骤，来推演验证一下在每个时间点、每个事务查询都能查到哪个版本的快照数据，也能加深一下理解（为了有些同学推演后想对比答案，我就把答案也写在下面了）。

  • 在时间点t2，事务101查询时生成的ReadView内容为：

    trx_list: 101
min_trx_id:101
max_trx_id:102
creator_trx_id:101

    当前时间点，版本链中只有一个快照(trx_id=100)，因为 trx_id(100)< min_trx_id(101)，符合算法的第（2）条规则，所以trx_id=100的这个快照对当前事务可见。

  • 在时间点t4，事务102查询时生成的ReadView内容为：

    trx_list: 101,102
min_trx_id:101
max_trx_id:103
creator_trx_id:102

    当前时间点，版本链中只有一个快照(trx_id=100)，因为 trx_id(100)< min_trx_id(101)，符合算法的第（2）条规则，所以trx_id=100的这个快照对当前事务可见。

  • 在时间点t6，事务103查询时生成的ReadView内容为：

    trx_list: 101,102,103
min_trx_id:101
max_trx_id:104
creator_trx_id:103
复制代码

    当前时间点，版本链中只有一个快照(trx_id=100)，因为 trx_id(100)< min_trx_id(101)，符合算法的第（2）条规则，所以trx_id=100的这个快照对当前事务可见。

  • 在时间点t8，事务101查询时用的ReadView和在t2时间点生成的ReadView一样：

    trx_list: 101
min_trx_id:101
max_trx_id:102
creator_trx_id:101

    当前时间点，版本链中有两个快照(trx_id=102 -> trx_id=100)，从版本链中的快照中，从最新的开始，依次判断：

    对于trx_id=102的快照，trx_id(102) >= max_trx_id(102) ，根据算法的第(3)条规则，trx_id=102的快照对当前事务不可见。这也验证了在RR隔离级别下，事务102修改但未提交的数据对于事务101应该不可见（RC都不可见了，更别说RR了）。

    对于trx_id=100的快照，因为 trx_id(100)< min_trx_id(101)，符合算法的第（2）条规则，所以trx_id=100的这个快照对当前事务可见。

  • 在时间点t9，事务102查询时用的ReadView和在t4时间点生成的ReadView一样：

    trx_list: 101,102
min_trx_id:101
max_trx_id:103
creator_trx_id:102

    当前时间点，版本链中有两个快照(trx_id=102 -> trx_id=100)，从版本链中的快照中，从最新的开始，依次判断：

    对于trx_id=102的快照，因为 trx_id(102) = creator_trx_id(102)，符合算法的第（1）条规则，所以trx_id=102的这个快照对当前事务可见。

  • 在时间点t11，事务103查询时用的ReadView和在t6时间点生成的ReadView一样：

    trx_list: 101,102,103
min_trx_id:101
max_trx_id:104
creator_trx_id:103

    当前时间点，版本链中有两个快照(trx_id=102 -> trx_id=100)，从版本链中的快照中，从最新的开始，依次判断：

    对于trx_id=102的快照，min_trx_id(101) <= trx_id(102) < max_trx_id(104) ，且trx_id(102) 在 trx_list(101,102,103) 中，说明当前事务生成ReadView时，修改该记录的事务是活跃事务（还未提交），根据算法的第(4)条规则，trx_id=102的快照对当前事务不可见。这也就验证了在RR隔离级别下，事务102修改且提交的数据对于事务103是不可见的。

  • 在时间点t14，事务101查询时生成的ReadView内容为：

    trx_list: 101
min_trx_id:101
max_trx_id:102
creator_trx_id:101

    当前时间点，版本链中有三个快照(trx_id=103 -> trx_id=102 -> trx_id=100)，从版本链中的快照中，从最新的开始，依次判断：

    对于trx_id=103的快照，trx_id(103) >= max_trx_id(102) ，根据算法的第(3)条规则，trx_id=103的快照对当前事务不可见。这也就验证了在RR隔离级别下，事务103修改且提交的数据对于事务101是不可见的。

    对于trx_id=102的快照，trx_id(102) >= max_trx_id(102) ，根据算法的第(3)条规则，trx_id=102的快照对当前事务不可见。这也就验证了在RR隔离级别下，事务102修改且提交的数据对于事务101是不可见的。

    对于trx_id=100的快照，trx_id(100) < min_trx_id(101) ，根据算法的第(2)条规则，trx_id=100的快照对当前事务可见。

参考

本文转载至: 深入理解MySQL的MVCC原理

以上是关于Mysql原理篇之MVCC原理--01的主要内容，如果未能解决你的问题，请参考以下文章

InnoDB的MVCC实现原理

MySQL的MVCC及实现原理

面试官：什么是MySQL 事务与 MVCC 原理？

深入理解MySQL的MVCC原理

深入理解MySQL的MVCC原理

深入理解MySQL的MVCC原理