MVCC浅析汇总
mvcc多版本并发控制的原理
mvcc多版本并发控制的原理多版本并发控制（MVCC）是一种用于数据库管理系统（DBMS）的并发控制方法，通过为每个事务创建多个版本的数据来实现事务的隔离和并发。
MVCC的原理主要基于事务的版本管理和数据的读取策略，它可以有效地提高数据库操作的并发性能和数据一致性。
本文将从MVCC的原理和实现方式、MVCC的优缺点以及应用场景等方面进行详细的介绍。
MVCC的原理和实现方式MVCC的原理主要基于事务的版本管理和数据的读取策略。
在MVCC 中，每个事务都会创建一个独立的版本，这个版本包含了事务开始时的数据快照，即使其他事务对数据进行了修改，这个版本也不会被更新。
当其他事务对数据进行了修改时，新版本的数据会被创建，原版本的数据则会保留。
这样可以确保事务在读取数据时可以得到一致性的数据快照，而不会受到其他事务的干扰。
另外，MVCC还使用了一种基于时间戳的读取策略，通过比较事务开始时的时间戳和数据版本的时间戳来确定是否可见。
MVCC的实现方式主要包括两种：基于时间戳的MVCC和基于版本号的MVCC。
基于时间戳的MVCC采用了事务开始时间戳和数据版本时间戳的比较来确定数据的可见性，这种方式可以有效地处理事务的读取冲突。
而基于版本号的MVCC则是通过为每个数据版本分配唯一的版本号，从而对数据的版本进行管理。
这种方式可以确保事务能够获取到一致的数据版本，并且能够减少时间戳比较的开销。
MVCC的优缺点MVCC具有以下几个优点：首先，MVCC可以提高数据库操作的并发性能。
由于MVCC可以为每个事务创建多个数据版本，因此事务之间的读写操作可以并发执行，不会出现读取-写入和写入-写入的互斥锁竞争，从而提高了数据库系统的并发能力。
其次，MVCC可以提高数据的一致性。
在MVCC中，每个事务都可以获取到一致性的数据版本，即使其他事务对数据进行了修改，也不会影响到当前事务的数据读取。
这样可以保证数据访问的一致性，减少了数据读取的干扰。
通俗易懂数据库mvcc讲解 -回复
通俗易懂数据库mvcc讲解-回复什么是数据库中的MVCC？在数据库中，MVCC（多版本并发控制）是一种用于实现并发控制的技术。
它允许多个事务同时读取和修改数据库中的数据，而不会相互干扰。
MVCC 通过为每个事务保留数据的历史版本来实现这一点。
当一个事务需要读取一个数据时，它会获取该数据的先前版本，这样它就可以保持一致性，而其他事务可以并发地修改数据。
MVCC的原理是什么？MVCC的原理可以简单地描述为：1. 每个数据对象都有一个版本号或时间戳，用于标识该数据的版本。
2. 当一个事务开始时，它会获取一个事务开始的时间戳。
3. 事务在修改时会创建一个新的数据对象版本，并将其附上事务开始的时间戳。
4. 数据库在执行查询时，并不使用最新的数据对象版本，而是使用其开始时间戳早于或等于查询事务时间戳的数据对象版本。
5. 如果一个事务查询到了一个较旧的数据版本，它会通过回滚到之前的版本来保证读取的数据一致性。
6. 事务完成后，它会将自己的时间戳释放，以便其他事务可以使用。
MVCC的优点是什么？MVCC具有以下几个优点：1. 高并发性：由于不需要锁定整个表或数据行，MVCC允许多个事务并发地读取和修改数据，从而提高了数据库的并发性能。
2. 降低冲突：由于事务之间读取的是不同的数据版本，而不是对同一个数据版本进行读写，可以有效降低事务之间的冲突，减少锁的争用，提高数据库的响应速度。
3. 一致性：通过读取之前的数据版本，事务可以保持一致性。
即使其他事务已经修改了数据，读取操作仍然可以看到之前的版本。
4. 高可靠性：MVCC提供了一种乐观的并发控制方法，减少了死锁和其他并发问题的可能性，提高数据库的可靠性。
MVCC的缺点是什么？MVCC也有一些缺点：1. 存储需求：由于每个数据对象都需要保存多个版本的数据，MVCC需要更多的存储空间来存储这些版本。
2. 清理过程：为了防止数据库无限增长，MVCC需要定期清理旧的数据版本。
深入浅出INNODB MVCC机制与原理
摘要：1、基础知识2、MVCC实现原理以及视图化理解（包含些测试以便理解）3、深MVCC实现机制一、基础知识事务：事务是一组原子性sql查询语句，被当作一个工作单元。
若mysql对改事务单元内的所有sql语句都正常的执行完，则事务操作视为成功，所有的sql语句才对数据生效，若sql中任意不能执行或出错则事务操作失败，所有对数据的操作则无效（通过回滚恢复数据）。
事务有四个属性：1、原子性：事务被认为不可分的一个工作单元，要么全部正常执行，要么全部不执行。
2、一致性：事务操作对数据库总是从一种一致性的状态转换成另外一种一致性状态。
3、隔离性：一个事务的操作结果在内部一致，可见，而对除自己以外的事务是不可见的。
4、永久性：事务在未提交前数据一般情况下可以回滚恢复数据，一旦提交（commit）数据的改变则变成永久（当然用update肯定还能修改）。
ps:MYSAM 引擎的数据库不支持事务，所以事务最好不要对混合引擎（如INNODB 、MYISAM）操作，若能正常运行且是你想要的最好，否则事务中对非支持事务表的操作是不能回滚恢复的。
读锁：也叫共享锁、S锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S 锁。
这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
写锁：又称排他锁、X锁。
若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。
这保证了其他事务在T释放A 上的锁之前不能再读取和修改A。
表锁：操作对象是数据表。
Mysql大多数锁策略都支持（常见mysql innodb），是系统开销最低但并发性最低的一个锁策略。
事务t对整个表加读锁，则其他事务可读不可写，若加写锁，则其他事务增删改都不行。
行级锁：操作对象是数据表中的一行。
是MVCC技术用的比较多的，但在MYISAM用不了，行级锁用mysql的储存引擎实现而不是mysql服务器。
MysqlMVCC机制原理详解
MysqlMVCC机制原理详解⽬录什么是MVCCMysql的锁和事务隔离级别Mysql的undo logMVCC的实现原理什么是MVCCMVCC，全称Multi-Version Concurrency Control，即多版本并发控制。
MVCC是⼀种并发控制的⽅法，⼀般在数据库管理系统中，实现对数据库的并发访问，在编程语⾔中实现事务内存。
我们知道，⼀般情况下我们使⽤mysql数据库的时候使⽤的是Innodb存储引擎，Innodb存储引擎是⽀持事务的，那么当多线程同时执⾏事务的时候，可能会出现并发问题。
这个时候需要⼀个能够控制并发的⽅法，MVCC就起到了这个作⽤。
Mysql的锁和事务隔离级别在理解MVCC机制的原理之前，需要先理解Mysql的锁机制和事务的隔离级别，抛开MyISAM存储引擎不谈，就Innodb存储引擎来说，分别有⾏锁和表锁两种锁，表锁就是⼀次操作锁住整张表，这样锁的粒度最⼤，但是性能也最低，不会出现死锁。
⾏锁就是⼀次操作锁住⼀⾏，这样锁的粒度⼩，并发度⾼，但是会出现死锁。
Innodb的⾏锁⼜分为共享锁（读锁）和排它锁（写锁），当⼀个事务对某⼀⾏加了读锁时，允许其他事务对这⼀⾏进⾏读操作，但是不允许进⾏写操作，也不允许其他事务对这⼀⾏执⾏加写锁，但是可以加读锁。
当⼀个事务对某⼀⾏加了写锁时，不允许其他事务对这⼀⾏进⾏写操作，但是可以读，同时不允许其他事务对这⼀⾏加读写锁。
下⾯来看⼀下Mysql的事务隔离级别，分为以下四种：1. 读未提交：⼀个事务可以读到其他事务还没有提交的数据，会出现脏读。
举个例⼦，有⼀张⼯资表，事务A先开启，然后执⾏查询id为1的员⼯的⼯资，假设此时的⼯资为1000，此时，事务B也开启，执⾏了更新操作，将id为1的员⼯⼯资减少了100，但是并未提交事务。
此时再执⾏事务A的查询操作，可以读到事务B已经更新的数据，如果此时事务B发⽣回滚，事务A读到的就是“脏”数据。
当事务A执⾏更新操作的话还可能产⽣幻读的情况。
MVCC并发控制与锁机制应用分析
MVCC并发控制与锁机制应用分析在数据库系统中，MVCC（Multi-Version Concurrency Control）并发控制是一种常用的技术，用于解决并发访问数据库时可能出现的读写冲突和数据一致性问题。
与传统的锁机制相比，MVCC更为灵活高效，能够提供更好的并发性能。
本文将对MVCC并发控制与锁机制应用进行详细分析。
一、MVCC概述MVCC是一种多版本并发控制机制，通过在数据库中保存多个版本的数据来实现并发事务的隔离。
每个事务在读取数据时可以看到自己版本的数据，不同事务之间的读写操作不会相互干扰，从而避免了传统锁机制下的阻塞和死锁问题。
MVCC的核心思想是在每个数据行中保存多个版本的历史数据，每个版本都有一个唯一的时间戳来标识其有效期。
当读取数据时，只需要根据事务的时间戳来选择相应版本的数据，这样可以实现读写之间的隔离性。
二、MVCC并发控制的优势相比传统的锁机制，MVCC有以下几个显著的优势：1. 无锁并发：MVCC的并发控制是通过版本管理实现的，不需要加锁来进行资源的互斥访问，因此可以实现更高程度的并发性。
2. 提高读写性能：由于读操作不会阻塞写操作，写操作也不会阻塞读操作，MVCC能够提高数据库的读写性能。
3. 高并发事务支持：MVCC能够支持大量并发事务的同时进行读写操作，降低了锁冲突的概率，提高了系统的吞吐能力。
三、MVCC的实现机制MVCC的实现主要依赖于以下两个机制：1. 版本链：在每个数据行中，通过版本链来保存不同版本的数据。
每个版本都有一个时间戳，版本链按时间戳的先后顺序进行排序。
2. 事务时间戳：每个事务都有一个唯一的时间戳，用于判断事务的可见性。
只有早于事务开始时间的版本才对该事务可见，当前事务的写操作会生成一个新的版本，并更新版本链。
四、锁机制与MVCC的对比传统的锁机制是通过加锁来实现并发控制的，而MVCC则通过版本管理来避免了加锁的过程。
下面是锁机制和MVCC的对比：1. 锁机制的弊端：锁机制存在死锁和阻塞等问题。
mvcc多版本并发控制的原理详解
mvcc多版本并发控制的原理详解摘要：一、MVCC 简介1.MVCC 概念2.MVCC 应用场景3.MVCC 的优势二、MVCC 原理详解1.数据存储结构2.读操作3.写操作4.事务处理5.数据一致性保证三、MVCC 在数据库中的实现1.数据库中的MVCC 应用2.MVCC 在数据库中的实现原理3.数据库MVCC 的优缺点分析四、MVCC 在其他领域的应用1.分布式系统中的MVCC 应用2.MVCC 在分布式系统中的实现原理3.分布式系统MVCC 的优缺点分析正文：一、MVCC 简介MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。
它是一种在并发访问下，保证数据一致性的技术。
MVCC 主要用于数据库系统，以提高数据库系统的并发性能。
在MVCC 中，每个事务处理过程中，数据以不同版本的形式存在，各个版本的数据之间互不干扰，从而实现并发控制。
1.MVCC 概念MVCC 是一种并发控制策略，通过为每个事务创建数据的“快照”，使事务处理过程中看到的数据是一致的，避免了因为并发访问导致的脏读、不可重复读等问题。
2.MVCC 应用场景MVCC 主要应用于数据库系统，解决在并发访问下，数据一致性的问题。
适用于读操作远多于写操作的场景，例如，数据分析、报表生成等应用。
3.MVCC 的优势MVCC 具有以下优势：a.提高并发性能：通过将读操作和写操作分离，降低了事务之间的冲突，提高了系统的并发性能。
b.保证数据一致性：在MVCC 中，事务处理过程中看到的数据是一致的，避免了脏读、不可重复读等问题。
c.简化事务处理：MVCC 无需等待其他事务完成，可以直接处理事务，简化了事务处理的流程。
二、MVCC 原理详解1.数据存储结构在MVCC 中，数据被划分为两个部分：数据本身和版本信息。
数据存储结构通常采用行数据+ 版本号的形式，版本号用于记录数据的版本信息。
2.读操作在进行读操作时，根据事务的隔离级别，可以读取到不同版本的数据。
MVCC多版本并发控制原理总结(最终版)
MVCC多版本并发控制原理总结（最终版）MVCC（Multi-Version Concurrency Control，多版本并发控制）是现代数据库管理系统中广泛采用的并发控制机制。
它通过为每个事务创建多个快照版本，实现了高并发性能和事务隔离性的双赢。
MVCC的基本原理是通过保存不同版本的数据来处理并发事务。
每个事务在读取数据时只能看到在事务开始之前提交的数据版本，而不会受到其他并发事务的影响。
当事务需要修改数据时，它会创建一个该数据的新版本，而不是直接在原来的数据上进行修改。
MVCC的实现包括以下几个关键步骤：1. 为每个事务分配事务ID（Transaction ID）。
事务ID是唯一标识一次事务的数字，用于区分不同的事务。
事务ID是根据事务开始时间和数据库系统的全局计数器生成的。
2. 每个数据记录都有一个版本号（Version Number）。
版本号是一个递增的整数，用于标识不同版本的数据记录。
当创建一个新版本的数据时，该数据的版本号将会被递增。
3. 每个数据记录都有两个额外的属性：创建时间戳（Creation Timestamp）和删除时间戳（Deletion Timestamp）。
创建时间戳记录了数据版本创建的时间，而删除时间戳则记录了数据版本被删除的时间。
这样，系统可以根据时间戳来判断哪些数据版本是有效的。
4. 在数据库中维护一个版本链表（Version Chain），用于保存不同版本的数据记录。
每个数据记录的版本链表按照版本号递减的顺序排列。
每个链表节点包含一个指向前一个版本的指针和数据记录的内容。
5.当一个事务需要读取数据时，它会根据事务ID和数据记录的版本链表来找到符合事务隔离级别的数据版本。
如果事务的开始时间早于数据版本的创建时间，并且事务的提交时间晚于数据版本的删除时间，则可以读取该数据版本。
6.当一个事务需要修改数据时，它会创建一个新版本的数据记录，同时将之前的版本链表进行更新。
MVCC总结
MVCC总结1 MVCC是什么可以认为MVCC是⾏锁的⼀个变种，⼤都实现了⾮阻塞的读操作，写操作也只锁定了必要的⾏。
2 MVCC能⼲什么通过保存数据在某个时间点的快照来实现的，根据事务开始时间的不同，每个事务对于同⼀张表，同⼀时刻看到的数据可能是不同的。
是隔离级别 RR 和RC实现隔离性的⼿段3 MVCC原理3.1 undo log事务号和回滚指针事务1，更新⼀⾏记录的时候锁⾏然后要把⽼记录放到undo log，同时改⾏的回滚指针要指向undo log中的改⾏之前版本的记录事务2 更新改⾏，该⾏记录每个版本形成⼀个undo 链。
在Innodb中存在purge线程，它会查询那些⽐现在最⽼的活动事务还早的undo log，并删除它们，从⽽保证undo log⽂件不⾄于⽆限增长。
undo log分insert和update undo log，因为insert时，原始的数据并不存在，所以回滚时把insert undo log丢弃即可3.2 事务链表MySQL中的事务在开始到提交这段过程中，都会被保存到⼀个叫trx_sys的事务链表中，这是⼀个基本的链表结构：事务链表中保存的都是还未提交的事务，事务⼀旦被提交，则会被从事务链表中摘除。
处在trx_sys中的事务，也叫做活跃事务 active transaction3.3 READ VIEWread view是mvcc最重要的⼀个概念，如果说mvcc不说read view，恐怕⾯试是通不过的，说不到点⼦上。
read view是⼲什么的呢？上⾯可知MVCC实现了多个并发事务更新同⼀⾏记录会时产⽣多个记录版本，那问题来了，新开始的事务如果要查询这⾏记录，应该获取到哪个版本呢？就需要read view来解决⾏的可见性问题。
low_limit_id 前者表⽰事务id⼤于此值的⾏记录都不可见。
事务号的最⼤值，最⾼⽔位。
up_limit_id 后者表⽰事务id⼩于此值的⾏记录都可见。
mvcc底层原理
mvcc底层原理MVCC（Multi-Version Concurrency Control）是一种并发控制技术，它用于保证数据库在多个事务同时访问时的一致性和隔离性。
MVCC底层原理是数据库系统中非常重要的一个概念，本文将从以下几个方面详细介绍MVCC底层原理。
一、MVCC概述1.1 MVCC定义MVCC是指在数据库中，每个事务可以看到不同版本的数据。
每次更新操作都会生成一个新版本的数据，并且这个新版本会与旧版本共存于数据库中。
因此，每个事务在读取数据时，可以选择读取某个版本的数据。
1.2 MVCC特点MVCC有以下几个特点：（1）多版本：每次更新操作都会生成一个新版本的数据，并且这个新版本会与旧版本共存于数据库中。
（2）并发控制：通过锁定机制实现并发控制。
（3）可重复读：同一个事务内部多次读取同一条记录时，能够看到相同的结果。
（4）隔离性：不同事务之间互相隔离，互不干扰。
二、MVCC实现原理2.1 版本链表在MVCC中，每次更新操作都会生成一个新版本的数据，并且这个新版本会与旧版本共存于数据库中。
为了实现这个功能，数据库需要维护一个版本链表。
版本链表中的每个节点都表示一个版本的数据。
2.2 事务ID在MVCC中，每个事务都有一个唯一的事务ID。
当一个事务开始时，它会分配一个新的事务ID，并且在所有更新操作中都会使用这个事务ID。
2.3 版本号在MVCC中，每个版本都有一个唯一的版本号。
版本号由两部分组成：创建该版本的事务ID和该事务内部生成该版本的序列号。
2.4 快照读和当前读在MVCC中，有两种读取数据的方式：快照读和当前读。
（1）快照读：快照读是指读取某个时间点上的数据。
当执行快照读时，数据库会根据给定的时间点，在版本链表中找到符合条件的最新版本，并返回该版本对应的数据。
（2）当前读：当前读是指读取最新的数据。
当执行当前读时，数据库会查找最新生成的数据，并返回该数据。
2.5 并发控制在MVCC中，通过锁定机制实现并发控制。
通俗易懂数据库mvcc讲解 -回复
通俗易懂数据库mvcc讲解-回复什么是数据库？数据库是一种用于存储和管理数据的软件系统。
什么是MVCC？MVCC是数据库的一个重要概念，全称是“Multiversion Concurrency Control”，即多版本并发控制。
MVCC 允许多个用户同时访问和修改数据库，确保数据的一致性和完整性。
为什么需要MVCC？在数据库系统中，常常会出现多个用户同时访问和修改同一份数据的情况，这就导致了并发控制的问题。
传统的并发控制方式是使用锁来解决并发访问的冲突，但是锁会引入诸多问题，如死锁、长时间的等待和低效率等。
而MVCC可以避免这些问题，提高并发访问效率。
MVCC的实现原理是什么？下面将详细介绍MVCC的实现原理：1. 版本号：MVCC使用版本号来标识每个事务对数据的修改，包括事务开始时的版本号和事务结束时的版本号。
2. 数据的多个版本：MVCC将每个数据对象的多个版本都保存在数据库中，每个版本用不同的版本号标识。
例如，每个事务开始时，数据库会为每个被修改的数据对象创建一个新的版本。
3. 快照：MVCC通过创建快照来实现事务的隔离性。
每个事务在开始时都会创建一个快照，快照中包含了事务开始时的数据库状态。
事务只能访问快照中的数据，而不会受到其他事务对数据库的修改影响。
4. 可见性判断：当一个事务要读取数据库中的数据时，MVCC会根据事务的版本号和数据对象的版本号来判断数据是否对事务可见。
如果数据的版本号早于事务的开始版本号，说明该数据在事务开始之前就被其他事务修改过，事务不可见该数据。
如果数据的版本号晚于事务的结束版本号，说明该数据在事务结束之后被其他事务修改，事务同样不可见该数据。
只有数据的版本号在事务的版本范围内，数据才对事务可见。
5. 冲突检测和回滚：当两个事务同时修改同一份数据时，会发生冲突。
MVCC通过检测事务之间的冲突来判断是否需要进行回滚操作。
如果两个事务冲突，后提交的事务将会被回滚，以保证数据的一致性。
MySQL的MVCC机制，详细解答
MySQL的MVCC机制，详细解答⽬录1、MVCC简介1.1 MVCC是什么？MVCC，Multi-Version Concurrency Control，多版本并发控制。
MVCC 是⼀种并发控制的⽅法，⼀般在数据库管理系统中，实现对数据库的并发访问；1.2 MVCC是为了解决什么？⼤多数的MYSQL事务型存储引擎,如,InnoDB，Falcon以及PBXT都不使⽤⼀种简单的⾏锁机制.事实上,他们都和MVCC–多版本并发控制来⼀起使⽤⼤家都应该知道,锁机制可以控制并发操作,但是其系统开销较⼤,⽽MVCC可以在⼤多数情况下代替⾏级锁,使⽤MVCC,能降低其系统开销 众所周知，在MYSQL中，MyISAM使⽤的是表锁，InnoDB使⽤的是⾏锁。
⽽InnoDB的事务分为四个隔离级别，其中默认的隔离级别REPEATABLE READ需要两个不同的事务相互之间不能影响，⽽且还能⽀持并发，这点悲观锁是达不到的，所以REPEATABLE READ采⽤的就是乐观锁，⽽乐观锁的实现采⽤的就是MVCC。
正是因为有了MVCC，才造就了InnoDB强⼤的事务处理能⼒。
MVCC解决的问题是读写互相不阻塞的问题，每次更新都产⽣⼀个新的版本，读的话可以读历史版本。
试想，如果⼀个数据只有⼀个版本，那么多个事务对这个数据进⾏读写是不是需要读写锁来保护?⼀个读写事务在运⾏的过程中在访问数据之前先加读/写锁这种实现叫做悲观锁，悲观体现在，先加锁，独占数据，防⽌别⼈加锁。
乐观锁呢，读写事务，在真正的提交之前，不加读/写锁，⽽是先看⼀下数据的版本/时间戳，等到真正提交的时候再看⼀下版本/时间戳，如果两次相同，说明别⼈期间没有对数据进⾏过修改，那么就可以放⼼提交。
乐观体现在，访问数据时不提前加锁。
在资源冲突不激烈的场合，⽤乐观锁性能较好。
如果资源冲突严重，乐观锁的实现会导致事务提交的时候经常看到别⼈在他之前已经修改了数据，然后要进⾏回滚或者重试，还不如⼀上来就加锁。
MySQL多版本并发控制和锁机制解析
MySQL多版本并发控制和锁机制解析在数据库系统中，多版本并发控制（Multiversion Concurrency Control，简称MVCC）是一种处理并发事务的机制。
它允许多个事务同时访问数据库，保证了数据的一致性和隔离性。
而为了实现MVCC，MySQL引入了锁机制，用于控制并发访问的顺序和范围。
本文将深入探讨MySQL的MVCC和锁机制，并分析其工作原理和应用场景。
一、多版本并发控制（MVCC）1. MVCC概述MVCC是MySQL中实现并发控制的一种机制，通过为每个事务保存多个版本的数据，使得多个事务能够并发访问同一数据表。
每个事务在开始时会获取一个系统版本号，该版本号用于确定其可以看到的数据版本。
在事务执行期间，如果其他事务对数据进行了修改操作，那么该事务只能看到在其开始之前已经提交的数据版本。
MVCC的核心思想是通过版本控制避免并发事务之间的冲突。
每个数据记录都会有一个版本号，事务在读取数据时使用的是事务开始时的版本号，而在写入数据时则会创建新的版本号。
这样，在并发环境下，每个事务都可以读取到一个一致性的数据版本，从而实现了数据的隔离性。
2. MVCC的实现原理MVCC的实现依靠两个关键机制：Undo Log和Read View。
2.1 Undo LogUndo Log是MySQL中用于回滚操作的日志。
在MVCC中，每个事务在对数据进行修改之前，会先将修改前的数据保存到Undo Log上。
当事务需要回滚时，就可以从Undo Log上恢复之前的数据。
2.2 Read ViewRead View是MySQL中用于控制事务读取的数据版本的机制。
每个事务在启动时都会创建一个Read View，该View包含了事务开始时当前数据库的全部活跃事务列表。
当事务需要读取数据时，会使用Read View来确定自己能够看到的数据版本。
Read View的实现借助了Undo Log和Read View链的概念。
mvcc多版本并发控制的原理详解
mvcc多版本并发控制的原理详解（原创实用版）目录1.MVCC 的概念与背景2.MVCC 的工作原理3.MVCC 的优势与应用场景4.MVCC 的局限性与改进方向正文【1.MVCC 的概念与背景】MVCC（Multi-Version Concurrency Control，多版本并发控制）是一种用于提高数据库并发性能的技术。
在高并发的场景下，为了保证数据的一致性和完整性，需要对数据库的读写操作进行控制。
传统的锁机制虽然能够实现数据一致性，但因为需要等待锁释放，会导致性能下降。
因此，为了解决这一问题，MVCC 应运而生。
【2.MVCC 的工作原理】MVCC 的工作原理可以概括为以下几点：1) 每个事务对于某一行记录看到的都是该记录在当前事务开始之前的版本，这些版本是由系统生成的，保存在每行记录的版本链中。
2) 当一个事务对某行记录进行修改时，系统会为该行记录创建一个新的版本，同时保留原来的版本。
因此，每个事务都可以看到一个时间点的数据库状态，而不会受到其他事务的影响。
3) 当事务提交时，系统会将该事务对记录所做的修改应用到对应的版本上，从而保证数据的一致性。
【3.MVCC 的优势与应用场景】MVCC 相较于传统的锁机制具有以下优势：1) 提高了并发性能：MVCC 通过让每个事务处理不同版本的数据，避免了等待锁释放的情况，从而提高了并发性能。
2) 降低了锁冲突：由于每个事务看到的都是数据的不同版本，因此锁冲突的概率大大降低。
3) 保证了数据一致性：MVCC 通过在事务提交时将修改应用到对应的版本上，保证了数据的一致性。
MVCC 广泛应用于需要高并发性能的场景，例如银行、金融、电商等行业的核心系统。
【4.MVCC 的局限性与改进方向】尽管 MVCC 具有很多优势，但仍然存在一些局限性：1) 版本链过长会导致存储开销增大，因此需要定期对版本链进行维护。
2) 在某些场景下，MVCC 可能无法完全满足事务的隔离性需求，需要与其他并发控制技术结合使用。
全网最全一篇数据库MVCC详解，不全你打我
全⽹最全⼀篇数据库MVCC详解，不全你打我什么是MVCC全称Multi-Version Concurrency Control，即多版本并发控制，主要是为了提⾼数据库的并发性能。
以下⽂章都是围绕InnoDB引擎来讲，因为myIsam不⽀持事务。
同⼀⾏数据平时发⽣读写请求时，会上锁阻塞住。
但mvcc⽤更好的⽅式去处理读—写请求，做到在发⽣读—写请求冲突时不⽤加锁。
这个读是指的快照读，⽽不是当前读，当前读是⼀种加锁操作，是悲观锁。
那它到底是怎么做到读—写不⽤加锁的，快照读和当前读⼜是什么⿁，跟着你们的贴⼼⽼哥，继续往下看。
当前读、快照读都是什么⿁什么是MySQL InnoDB下的当前读和快照读？当前读它读取的数据库记录，都是当前最新的版本，会对当前读取的数据进⾏加锁，防⽌其他事务修改数据。
是悲观锁的⼀种操作。
如下操作都是当前读：select lock in share mode (共享锁)select for update (排他锁)update (排他锁)insert (排他锁)delete (排他锁)串⾏化事务隔离级别快照读快照读的实现是基于多版本并发控制，即MVCC，既然是多版本，那么快照读读到的数据不⼀定是当前最新的数据，有可能是之前历史版本的数据。
如下操作是快照读：不加锁的select操作（注：事务级别不是串⾏化）快照读与mvcc的关系MVCCC是“维持⼀个数据的多个版本，使读写操作没有冲突”的⼀个抽象概念。
这个概念需要具体功能去实现，这个具体实现就是快照读。
（具体实现下⾯讲）听完贴⼼⽼哥的讲解，是不是瞬间茅塞顿开。
数据库并发场景读-读：不存在任何问题，也不需要并发控制读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读写-写：有线程安全问题，可能会存在更新丢失问题，⽐如第⼀类更新丢失，第⼆类更新丢失MVCC解决并发哪些问题？mvcc⽤来解决读—写冲突的⽆锁并发控制，就是为事务分配单向增长的时间戳。
浅谈数据库并发控制-锁和MVCC
浅谈数据库并发控制-锁和MVCC在学习⼏年编程之后，你会发现所有的问题都没有简单、快捷的解决⽅案，很多问题都需要权衡和妥协，⽽本⽂介绍的就是数据库在并发性能和可串⾏化之间做的权衡和妥协 -并发控制机制。
如果数据库中的所有事务都是串⾏执⾏的，那么它⾮常容易成为整个应⽤的性能瓶颈，虽然说没法⽔平扩展的节点在最后都会成为瓶颈，但是串⾏执⾏事务的数据库会加速这⼀过程；⽽并发（Concurrency）使⼀切事情的发⽣都有了可能，它能够解决⼀定的性能问题，但是它会带来更多诡异的错误。
引⼊了并发事务之后，如果不对事务的执⾏进⾏控制就会出现各种各样的问题，你可能没有享受到并发带来的性能提升就已经被各种奇怪的问题折磨的欲仙欲死了。
概述如何控制并发是数据库领域中⾮常重要的问题之⼀，不过到今天为⽌事务并发的控制已经有了很多成熟的解决⽅案，⽽这些⽅案的原理就是这篇⽂章想要介绍的内容，⽂章中会介绍最为常见的三种并发控制机制：分别是悲观并发控制、乐观并发控制和多版本并发控制，其中悲观并发控制其实是最常见的并发控制机制，也就是锁；⽽乐观并发控制其实也有另⼀个名字：乐观锁，乐观锁其实并不是⼀种真实存在的锁，我们会在⽂章后⾯的部分中具体介绍；最后就是多版本并发控制（MVCC）了，与前两者对⽴的命名不同，MVCC 可以与前两者中的任意⼀种机制结合使⽤，以提⾼数据库的读性能。
既然这篇⽂章介绍了不同的并发控制机制，那么⼀定会涉及到不同事务的并发，我们会通过⽰意图的⽅式分析各种机制是如何⼯作的。
悲观并发控制控制不同的事务对同⼀份数据的获取是保证数据库的⼀致性的最根本⽅法，如果我们能够让事务在同⼀时间对同⼀资源有着独占的能⼒，那么就可以保证操作同⼀资源的不同事务不会相互影响。
最简单的、应⽤最⼴的⽅法就是使⽤锁来解决，当事务需要对资源进⾏操作时需要先获得资源对应的锁，保证其他事务不会访问该资源后，在对资源进⾏各种操作；在悲观并发控制中，数据库程序对于数据被修改持悲观的态度，在数据处理的过程中都会被锁定，以此来解决竞争的问题。
通俗易懂数据库mvcc讲解 -回复
通俗易懂数据库mvcc讲解-回复什么是数据库MVCC（多版本并发控制）以及其原理和应用场景？在数据库系统中，MVCC（Multi-Version Concurrency Control）即多版本并发控制, 是一种常用的数据库并发控制技术。
它通过为每个数据库事务创建一个独立的版本数据副本，实现并发读写操作的隔离性和一致性。
MVCC可以减少数据库锁的竞争，提高数据库并发性能。
为了更好地理解MVCC的原理和应用场景，我们需要先了解传统并发控制技术以及其存在的问题。
在数据库中，读取和写入操作可以同时出现，这可能导致数据的不一致性问题，如丢失修改、脏读和幻影读等。
为了解决这些问题，传统的并发控制技术通常使用锁来保证事务的隔离性。
然而，锁会导致大量的资源竞争和阻塞，降低了数据库的并发性能。
MVCC通过使用多版本的数据副本来解决传统并发控制技术中存在的问题。
它为每个数据库事务创建一个独立的版本数据副本，包含了事务开始时数据的快照。
这样一来，每个事务只需要读取自己版本的数据，而不会互相干扰。
同时，MVCC也允许多个事务同时修改同一份数据，不会出现互相阻塞的情况。
MVCC的实现原理主要包括三个方面：版本号、回滚指针和可见性判断。
首先，每个事务在开始时将会获得一个唯一的版本号。
在MVCC中，每个数据行都会有一个版本号，表示该行的修改历史。
通过版本号可以判断一个事务对数据是否有读写权限，从而保证事务的隔离性。
当一个事务需要读取一个数据行时，系统会检查该行的版本号是否小于或等于当前事务的版本号，如果是，则表示该数据行在事务开始之前没有被修改过，可以读取。
如果不是，则需要判断该行是否是当前事务正在操作的数据，如果是则可以读取，否则需要等待。
其次，MVCC使用回滚指针来处理事务的回滚操作。
当一个事务提交或者回滚时，系统会将该事务对数据的修改记录在回滚指针中，以便之后的事务可以找回之前的版本数据。
如果一个读操作发现一个数据的版本号超过了当前事务的版本号，它可以通过回滚指针找到之前的版本数据。
通俗易懂数据库mvcc讲解 -回复
通俗易懂数据库mvcc讲解-回复什么是MVCC（Multi-Version Concurrency Control）？MVCC（多版本并发控制）是一种数据库管理系统中的并发控制机制，用于处理数据库中多个事务同时读取和写入相同数据时的冲突。
它通过为每个事务创建一个独立的数据版本，从而避免了事务之间的争用。
MVCC的工作原理是什么？MVCC通过为每个事务创建独立的数据版本来实现并发控制。
当事务读取数据时，它只会读取已提交的数据版本。
而当事务修改数据时，它实际上是创建了一个新的数据版本，而原始数据版本仍然保持不变。
在MVCC中，每个数据版本都有一个唯一的时间戳或事务ID。
事务只能读取早于其开始时间的数据版本，并且不能读取由其它正在进行的事务修改但尚未提交的数据版本。
这样，MVCC可以确保事务之间不会相互干扰，从而提高数据库的并发性能和事务的隔离级别。
MVCC的优点是什么？1. 并发性能优化：MVCC可以在一定程度上提高数据库的并发性能，因为它允许多个事务同时读取和写入相同的数据，而不会发生阻塞或争用。
2. 读取一致性：MVCC可以确保读取操作的一致性，即每个事务只能读取到已提交的数据版本，不会读取到其他事务尚未提交的修改。
3. 事务隔离性：MVCC提供了较高的事务隔离级别，避免了脏读（读取到其他事务尚未提交的数据）、不可重复读（同一事务内多次读取得到不同结果）和幻读（一个事务在读取数据时发现有新的数据插入）等问题。
MVCC的缺点是什么？1. 存储空间需求：由于每个事务都会创建自己的数据版本，因此MVCC 需要额外的存储空间来存储这些版本，可能会增加数据库的存储需求。
2. 版本回收：随着时间的推移，数据库中可能会积累大量的过期版本，如果没有及时回收这些版本，可能会导致存储空间的浪费。
3. 更新操作开销：当一个事务修改数据时，它实际上是创建了一个新的数据版本，而旧的数据版本仍然保持不变。
这可能会导致更新操作的开销增加。
mvcc的理解
mvcc的理解MVCC（Multi-Version Concurrency Control）是一种数据库并发控制技术，用于解决在并发环境下数据库读写操作的冲突问题。
本文将从MVCC的原理、实现方式和优缺点三个方面详细介绍MVCC 的理解。
一、MVCC的原理MVCC的核心思想是通过为每个事务分配一个唯一的事务ID （Transaction ID），并为每个数据行保存多个版本。
在事务执行过程中，读操作可以读取已提交的最新版本，而写操作则会创建一个新版本，并将新版本的事务ID与该数据行关联。
这样可以实现读操作不受写操作的影响，同时也保证了事务的隔离性。
二、MVCC的实现方式1. 为每个数据行添加隐藏的事务ID列：在每个数据行中添加一个隐藏的事务ID列，用于记录最后更新该数据行的事务ID。
这样可以通过比较事务ID来判断数据行是否对当前事务可见。
2. 使用版本链表：为每个数据行维护一个版本链表，其中每个版本节点都包含了事务ID、数据值和指向下一个版本的指针。
读操作时，根据事务ID的大小关系遍历版本链表，找到最适合当前事务的数据版本。
三、MVCC的优缺点1. 优点：- 高并发性：MVCC允许多个事务同时读取数据，提高了数据库的并发性能。
- 高隔离性：MVCC通过多版本的方式，避免了读写操作之间的冲突，保证了事务的隔离性。
- 无锁操作：MVCC不需要使用传统的悲观锁或乐观锁机制，减少了锁的竞争，提高了数据库的性能。
- 低冲突率：由于读写操作之间不存在冲突，减少了事务之间的等待时间，提高了数据库的吞吐量。
2. 缺点：- 存储空间开销：由于需要为每个数据行保存多个版本，MVCC 会增加数据库的存储空间开销。
- 逻辑复杂性：MVCC的实现相对复杂，需要维护版本链表和事务ID的关系，增加了数据库系统的开发难度。
- 读操作性能损失：在MVCC中，读操作需要遍历版本链表，找到适合当前事务的数据版本，这可能导致读操作的性能损失。
mvcf数据要素解析
mvcf数据要素解析MVC是指模型-视图-控制器的软件架构模式，用于组织和管理应用程序的代码。
它是一种分离关注点（Separation of Concerns）的设计原则，旨在实现代码的可重用性、可维护性和可扩展性。
模型（Model）指代应用程序中用于存储和处理数据的组件。
它负责处理应用程序的业务逻辑和数据操作，例如读取、更新和删除数据。
模型通常是应用程序的核心部分，与数据库或其他数据源进行交互，提供数据给视图进行展示。
视图（View）是用户界面的表示层，负责展示数据和与用户进行交互。
视图从模型中获取数据，并将其呈现给用户。
它可以是网页、图形用户界面（GUI）或其他形式的用户界面。
视图通常是被动的，它不会直接修改数据，而是通过控制器来实现。
控制器（Controller）是模型和视图之间的协调者。
它接收用户的输入并根据用户请求调用相应的模型和视图来完成任务。
控制器处理用户的输入，并根据输入的内容来调用适当的模型方法。
它还可以更新模型的状态，然后将更新后的数据传递给视图进行展示。
数据要素解析指的是对数据进行分析和解释的过程。
在MVC模式中，数据要素解析通常发生在控制器和模型之间。
控制器从视图获取用户输入的数据，并将其解析成模型可以理解的格式。
然后，控制器将解析后的数据传递给模型进行处理。
模型根据数据要素解析的结果来执行相应的业务逻辑，完成数据处理的任务。
总结起来，MVC模式中的数据要素解析是指控制器接收用户输入的数据，并将其解析成模型可以理解的格式，然后传递给模型进行处理。
这种分离和解析的方式可以提高代码的可读性和可维护性，使应用程序更加灵活和可扩展。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
MVCC浅析在并发读写数据库时，读操作可能会不一致的数据（脏读）。
为了避免这种情况，需要实现数据库的并发访问控制，最简单的方式就是加锁访问。
由于，加锁会将读写操作串行化，所以不会出现不一致的状态。
但是，读操作会被写操作阻塞，大幅降低读性能。
在java concurrent包中，有copyonwrite系列的类，专门用于优化读远大于写的情况。
而其优化的手段就是，在进行写操作时，将数据copy一份，不会影响原有数据，然后进行修改，修改完成后原子替换掉旧的数据，而读操作只会读取原有数据。
通过这种方式实现写操作不会阻塞读操作，从而优化读效率。
而写操作之间是要互斥的，并且每次写操作都会有一次copy，所以只适合读大于写的情况。
MVCC的原理与copyonwrite类似，全称是Multi-Version Concurrent Control，即多版本并发控制。
在MVCC协议下，每个读操作会看到一个一致性的snapshot，并且可以实现非阻塞的读。
MVCC允许数据具有多个版本，这个版本可以是时间戳或者是全局递增的事务ID，在同一个时间点，不同的事务看到的数据是不同的。
实现原理：------------------------------------------------------------------------------------------> 时间轴|-------R(T1)-----||-----------U(T2)-----------|如上图，假设有两个并发操作R(T1)和U(T2)，T1和T2是事务ID，T1小于T2，系统中包含数据a = 1(T1)，R和W的操作如下：R：read a (T1)U：a = 2 (T2)R（读操作）的版本T1表示要读取数据的版本，而之后写操作才会更新版本，读操作不会。
在时间轴上，R晚于U，而由于U在R开始之后提交，所以对于R是不可见的。
所以，R只会读取T1版本的数据，即a = 1。
由于在update操作提交之前，不能影响已有数据的一致性，所以不会改变旧的数据，update操作会被拆分成insert + delete。
需要标记删除旧的数据，insert新的数据。
只有update提交之后，才会影响后续的读操作。
而对于读操作而且，只能读到在其之前的所有的写操作，正在执行中的写操作对其是不可见的。
上面说了一堆的虚的理论，下面来点干活，看一下mysql的innodb引擎是如何实现MVCC的。
innodb会为每一行添加两个字段，分别表示该行创建的版本和删除的版本，填入的是事务的版本号，这个版本号随着事务的创建不断递增。
在repeated read的隔离级别（事务的隔离级别请看这篇文章）下，具体各种数据库操作的实现：select：满足以下两个条件innodb会返回该行数据：（1）该行的创建版本号小于等于当前版本号，用于保证在select操作之前所有的操作已经执行落地。
（2）该行的删除版本号大于当前版本或者为空。
删除版本号大于当前版本意味着有一个并发事务将该行删除了。
insert：将新插入的行的创建版本号设置为当前系统的版本号。
delete：将要删除的行的删除版本号设置为当前系统的版本号。
update：不执行原地update，而是转换成insert + delete。
将旧行的删除版本号设置为当前版本号，并将新行insert同时设置创建版本号为当前版本号。
其中，写操作（insert、delete和update）执行时，需要将系统版本号递增。
由于旧数据并不真正的删除，所以必须对这些数据进行清理，innodb会开启一个后台线程执行清理工作，具体的规则是将删除版本号小于当前系统版本的行删除，这个过程叫做purge。
通过MVCC很好的实现了事务的隔离性，可以达到repeated read级别，要实现serializable还必须加锁。
问题最近项目中遇到了一个分布式系统的并发控制问题。
该问题可以抽象为：某分布式系统由一个数据中心D和若干业务处理中心L1，L2 ... Ln组成；D本质上是一个key-value存储，它对外提供基于HTTP协议的CRUD操作接口。
L的业务逻辑可以抽象为下面3个步骤：1.read: 根据keySet {k1, ... kn}从D获取keyValueSet {k1:v1, ...kn:vn}2.do: 根据keyValueSet进行业务处理，得到需要更新的数据集keyValueSet' {k1':v1', ... km':vm'} (注：读取的keySet和更新的keySet'可能不同)3.update: 把keyValueSet'更新到D （注：D保证在一次调用更新多个key的原子性）在没有事务支持的情况下，多个L进行并发处理可能会导致数据一致性问题。
比如，考虑L1和L2的如下执行顺序：1.L1从D读取key:123对应的值1002.L2从D读取key:123对应的1003.L1对值增加1，将key:123更新为100 + 14.L2对值增加2，将key:123更新为100 + 2如果L1和L2串行执行，key:123对应的值将为103，但上面并发执行中L1的执行效果完全被L2所覆盖，实际key:123所对应的值变成了102。
解决方案1：锁机制为了让L的处理可串行化(Serializable)，一种最直接的解决方案就是考虑为D 加上基于锁的简单事务。
让L在进行业务处理前先锁定D，完成以后释放锁。
另外，为了防止持有锁的L由于某种原因长时间未提交事务，D还需要具有超时机制，当L尝试提交一个已超时的事务时会得到一个错误响应。
本方案的优点是实现简单，缺点是锁定了整个数据集，粒度太大；时间上包含了L的整个处理时间，跨度太长。
为此，可以考虑把锁定粒度降低到数据项级别，按key进行锁定，但这又会带来其他的问题。
由于更新的keySet'可能是事先不确定的，所以可能无法在开始事务时锁定所有的key；如果分阶段来锁定需要的key，又可能出现死锁(Deadlock)问题。
另外，按key锁定在有锁争用的情况下并不能解决锁定时间太长的问题。
所以，按key锁定仍然存在重要的不足之处。
解决方案2：多版本并发控制为了实现可串行化，同时避免锁机制存在的各种问题，我们可以采用基于多版本并发控制（Multiversion concurrency control，MVCC）思想的无锁并发机制。
人们一般把基于锁的并发控制机称成为悲观机制，而把MVCC等机制称为乐观机制。
这是因为锁机制是一种预防性的，读会阻塞写，写也会阻塞读，当锁定粒度较大，时间较长是并发性能就不会太好；而MVCC是一种后验性的，读不阻塞写，写也不阻塞读，等到提交的时候才检验是否有冲突，由于没有锁，所以读写不会相互阻塞，从而大大提升了并发性能。
我们可以借用源代码版本控制来理解MVCC，每个人都可以自由地阅读和修改本地的代码，相互之间不会阻塞，只在提交的时候版本控制器会检查冲突，并提示merge。
目前，Oracle、PostgreSQL和MySQL都已支持基于MVCC的并发机制，但具体实现各有不同。
MVCC的一种简单实现是基于CAS（Compare-and-swap）思想的有条件更新（Conditional Update）。
普通的update参数只包含了一个keyValueSet'，Conditional Update在此基础上加上了一组更新条件conditionSet { ... data[keyx]=valuex, ... }，即只有在D满足更新条件的情况下才将数据更新为keyValueSet'；否则，返回错误信息。
这样，L就形成了如下图所示的Try/Conditional Update/(Try again)的处理模式：虽然对单个L来讲不能保证每次都成功更新，但从整个系统来看，总是有任务能够顺利进行。
这种方案利用Conditional Update避免了大粒度和长时间的锁定，当各个业务之间资源争用不大的情况下，并发性能很好。
不过，由于Conditional Update需要更多的参数，如果condition中value的长度很长，那么每次网络传送的数据量就会比较大，从而导致性能下降。
特别是当需要更新的keyValueSet'很小，而condition很大时，就显得非常不经济。
为了避免condition太大所带来的性能问题，可以为每条数据项增加一个int型的版本号字段，由D维护该版本号，每次数据有更新就增加版本号；L在进行Conditional Update时，通过版本号取代具体的值。
另一个问题是上面的解决方案假设了D是可以支持Conditional Update的；那么，如果D是一个不支持Conditional Update的第三方的key-value存储怎么办呢？这时，我们可以在L和D之间增加一个P作为代理，所有的CRUD操作都必须经过P，让P来进行条件检查，而实际的数据操作放在D。
这种方式实现了条件检查和数据操作的分离，但同时降低了性能，需要在P中增加cache，提升性能。
由于P是D的唯一客户端；所以，P的cache管理是非常简单的，不必像多客户端情形担心缓存的失效。
不过，实际上，据我所知redis和Amazon SimpleDB都已经有了Conditional Update的支持。
锁机制和MVCC对比上面介绍了锁机制和MVCC的基本原理，但是对于它们分别适用于什么场合，不同的场合下两种机制优劣具体表现在什么地方还不是很清楚。
这里我就对一些典型的应用场景进行简单的分析。
需要注意的是下面的分析不针对分布式，锁机制和MVCC两种机制在分布式系统、单数据库系统、甚至到内存变量各个层次都存在。
场景1：对读的响应速度要求高有一类系统更新特别频繁，并且对读的响应速度要求很高，如股票交易系统。
在锁机制下，写会阻塞读，那么当有写操作时，读操作的响应速度就会受到影响；而MVCC不存在读写锁，读操作是不受任何阻塞的，所以读的响应速度会更快更稳定。
场景2：读远多于写对于许多系统来讲，读操作的比例往往远大于写操作，特别是某些海量并发读的系统。
在锁机制下，当有写操作占用锁，就会有大量的读操作被阻塞，影响并发性能；而MVCC可以保持比较高且稳定的读并发能力。
场景3：写操作冲突频繁如果系统中写操作的比例很高，且冲突频繁，这时就需要仔细评估。
假设两个有冲突的业务L1和L2，它们在单独执行是分别耗时t1，t2。
在锁机制下，它们的总时间大约等于串行执行的时间：T = t1 + t2而在MVCC下，假设L1在L2之前更新，L2需要retry一次，它们的总时间大约等于L2执行两次的时间（这里假设L2的两次执行耗时相等，更好的情况是，如果第1次能缓存下部分有效结果，第二次执行L2耗时是可能减小的）：T’ = 2 * t2这时关键是要评估retry的代价，如果retry的代价很低，比如，对某个计数器递增，又或者第二次执行可以比第一次快很多，这时采用MVCC机制就比较适合。