定义
MVCC是多版本并发控制 Multi-Version Concurrent Contrl。

它是MySQL中的提高性能的一种方式，配合Undo log 和版本链，替代锁，让不同事物的读-写、写-读操作可以并发的执行，从而提升系统的性能。

MVCC 在 MySQL InnoDB 中的实现主要是为了提高数据库并发性能。一般是在使用读已提交（PEAD COMMITTED）和可重复读（REPEATABLE READ）隔离级别的事务中实现。

用自己的话说就是：
多版本意思是指数据库中一条数据有多个版本同时存在，在某个事务对其进行具体操作的时候，是需要查看这一条记录的隐藏列事务版本的id，比对事务id并根据事物的隔离级别从而去判断是哪个版本的数据。

准确的说，MVCC多版本并发控制指的是 “维持一个数据的多个版本，使得读写操作没有冲突” 这么一个概念。

当前读和快照读
在了解MVCC之前，还要了解一下，MySQL InnoDB中的当前读和快照读。

当前读
像 select in share mode（共享锁），select for update，update，insert，delete（排它锁）这些操作都是一种当前读，当前读就是它读取的是记录的最新版本的数据。读取时还要保证其他并发事务不能修改当前的记录，会对读取的记录进行加锁。

快照读
就像不加锁的select操作就是快照读，即不加锁的非阻塞读；

快照读的前提就是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；

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

既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。

说白了就是MVCC就是为了实现读-写冲突不加锁，而这个读指的就是快照读，而非当前读，当前读实际上就是一种加锁的操作，是悲观锁的实现。

MVCC的优点
MVCC在MySQL InnoDB中的实现主要是为了提高数据库的并发性能，用更好的方式去处理读-写或写-读之间的冲突，也能做到不加锁，非阻塞并发读，提高了数据库并发读写的性能。
MVCC还可以解决脏读，幻读，不可重复读等事务隔离问题。但它还不能解决更新丢失的问题。
所以MVCC能够解决读-写之间的并发控制，但它不能解决写-写之间的的并发控制

总而言之，MVCC就是后人通过再研究出的一种机制，在早期程序只能采用悲观锁这种性能不佳的形式去解决读-写 写-写之间的冲突问题，为现在有了MVCC我们就可以打组合拳。

现在MVCC + 悲观锁 、 MVCC + 乐观锁这样的机制来解决。MVCC解决读-写冲突问题，锁解决写-写之间的冲突。

这样组合下来，最大程度上提高了数据库的并发执行性能。

基本原理
因为MVCC的目的就是控制并发控制的，在数据库中的实现，为了解决读写的冲突问题。

它的实现原理主要依赖3个模块：隐藏字段、undo日志、Read View来实现的。

隐藏字段
对于使用 InnoDB 存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列。

● trx_id：每次对某条聚簇索引记录进行改动的时候，都会把对应的事务id赋值给trx_id进行记录的隐藏列。

● roll_pointer：在每次对某条聚簇索引记录进行改动的时候，都会把旧版本写入undo日志当中，然后这个隐藏列就相当于一个指针的作用，我们可以通过roll_pointer来找到该记录修改之前的信息。

undo日志
undo log主要分为两种：

insert undo log：
代表事务在insert新记录时产生的undo log，只在事务回滚时需要，并且在事务提交后就立即删除。

update undo log：
事务在进行update或delete时产生的undo log；不仅在事务回滚的时需要，在快照时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除。

Read View（读视图）
对于使用READ UNCOMMITTED（读未提交）隔离级别的事务来说，直接读取记录的最新版本就好了，对于使用SERIALIZABLE（串行化）隔离级别的事务来说，使用加锁的方式来访问记录。

所以在InnoDB引擎中设计了一个ReadView的概念。
Read View就是事务进行快照读操作的时候产生的读视图（Read View），在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID（当每个事务开启时，都会分配一个ID，这个ID是自增的，所以最新的事务，ID越大）。

在MySQL当中，READ COMMITTED和REPEATABLE READ 隔离级别的一个非常大的区别就是它们生成的Read View 的时机不同。

● READ COMMITTED：每次读取数据前都生成一个ReadView；
● REPEATABLE READ：在第一个读取数据时生成一个ReadView；

版本链
前面说到，每次数据更新的时候都更新undo 日志，在undo 日志中就会出来一个版本链的情况。

那么它的主要执行流程如下所示：

假设对事务id为1001的行做操作

现在来了一个事务1002 过来修改name为“李四”

在事务1001中修改该行的数据时，数据库先会对其加排它锁。

然后把该行数据拷贝到nudo日志中，所为旧记录。

拷贝完成后，就修改name为“李四”，并且修改事务id为当前事务的id，回滚指针指向副本的记录

提交事务，释放锁

现在再来了一个事务1003 过来修改age为20

在事务1002中修改该行的数据时，数据库先会对其加排它锁。

然后把该行数据拷贝到nudo日志中，所为旧记录。

拷贝完成后，就修改agewei20，并且修改事务id为当前事务的id，回滚指针指向副本的记录

提交事务，释放锁

从上面就可以看出，不同的事务或者相同事务对同一记录修改的时候，会导致日志中成为一条记录版本线性表，这个就是版本链。

undo日志中链首即就是最新的旧记，链尾就是最早的旧记录。

但是在实际当中，会在第一个事务完成提交后，就可能被purge线程删除丢失，这里为了演示，就留在这了。

为了节省磁盘空间，InnoDB有专门的purge线程来清理undo log中的记录。为了不影响MVCC的正常工作，purge线程自己也维护了一个read view（这个read view相当于系统中最老活跃事务的read view）

————————————————
版权声明：本文为CSDN博主「星辰与晨曦」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_45970271/article/details/124380044