《MySQL高级篇》十四、多版本并发控制
1. 什么是MVCCMVCC (Multiversion Concurrency Control)，多版本并发控制。顾名思义，MVCC是通过数据行的多个版本管理来实现数据库的并发控制。这项技能使得在InnoDB的事件隔离级别下实行一致性读利用有了保证。换言之，就是为了查询一些正在被另一个事件更新的行，并且可以看到它们被更新之前的值，如许在做查询的时间就不用等待另一个事件释放锁。
MVCC没有正式的标准，在差别的DBMS中 MVCC的实现方式可能是差别的，也不是普遍利用的(大家可以参考相关的DBMS文档)。这里讲解InnoDB 中 MVCC的实现机制（MySQL别的的存储引擎并不支持它)。
2. 快照读与当前读
MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式行止理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非壅闭并发读，而这个读指的就是快照读，而非当前读。当前读实际上是一种加锁的利用，是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。
2.1 快照读
快照读又叫一致性读，读取的是快照数据。不加锁的简单的 SELECT 都属于快照读，即不加锁的非壅闭读；好比如许：
SELECT * FROM player WHERE ...
之所以出现快照读的环境，是基于提高并发性能的考虑，快照读的实现是基于MVCC，它在很多环境下，制止了加锁利用，降低了开销。
既然是基于多版本，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。
快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。
2.2 当前读
当前读读取的是记载的最新版本（最新数据，而不是历史版本的数据），读取时还要保证其他并发事件不能修改当前记载，会对读取的记载举行加锁。加锁的 SELECT，或者对数据举行增删改都会举行当前读。好比：
SELECT * FROM student LOCK IN SHARE MODE; # 共享锁
SELECT * FROM student FOR UPDATE; # 排他锁
INSERT INTO student values ... # 排他锁
DELETE FROM student WHERE ... # 排他锁
UPDATE student SET ... # 排他锁
注意：InnoDB增删改默认加X锁，查默认不加锁
3. 复习
3.1 再谈隔离级别
事件有 4 个隔离级别，可能存在三种并发问题：（准确来说是四种，还有一种：脏写）
https://i-blog.csdnimg.cn/blog_migrate/7af56fe79b38cbf8765ba4439bc1fb30.png
在MySQL中，默认的隔离级别是可重复读，可以解决脏读和不可重复读的问题，如果仅从界说的角度来看，它并不能办理幻读问题。如果想要办理幻读问题，就必要采用串行化的方式，也就是将隔离级别提升到最高，但如许一来就会大幅降低数据库的事件并发本领
MVCC可以不采用锁机制，而是通过乐观锁的方式来办理不可重复读和幻读问题！它可以在大多数环境下替代行级锁，降低系统的开销。
https://i-blog.csdnimg.cn/blog_migrate/5ebedf9663ed5902bdf242055165b2ac.png
在口试的时间要按照第二幅图举行回答哦~
如果采用加锁的方式，那么就是间隙锁办理幻读问题。
3.2 隐蔽字段、Undo Log版本链
回顾一下undo日志的版本链，对于利用InnoDB存储引擎的表来说，它的聚簇索引记载中都包含两个必要的隐蔽列。
[*]trx_id : 每次一个事件对某条聚簇索引记载举行改动时，都会把该事件的事件id赋值给trx_id隐蔽列
[*]roll_pointer:每次对某条聚簇索引记载举行改动时，都会把旧的版本写入到undo日志中，然后这个隐蔽列就相当于一个指针，可以通过它来找到该记载修改前的信息。
**举例：**student表数据如下
SELECT * FROM student ;
/*
+----+--------+--------+
| id | name | class|
+----+--------+--------+
|1 | 张三 | 一班 |
+----+--------+--------+
1 row in set (0.07 sec)
*/
假设插入该记载的事件id为8，那么此刻该条记载的示意图如下所示:
https://i-blog.csdnimg.cn/blog_migrate/d4eb404cd3011daf7cfafb5707b61c5b.png
insert undo只在事件回滚时起作用，当事件提交后，该类型的undo日志就没用了，它占用的Undo Log Segment也会被系统回收（也就是该undo日志占用的Undo页面链表要么被重用，要么被释放)。
假设之后两个事件id分别为10、20的事件对这条记载举行UPDATE 利用，利用流程如下:
发生时间次序事件10事件201BEGIN;2BEGIN;3UPDATE student SET name=“李四”
WHERE id=1;4UPDATE student SET name=“王五”
WHERE id=1;5COMMIT;6UPDATE student SET name=“钱七”
WHERE id=1;7UPDATE student SET name=“宋八”
WHERE id=1;8COMMIT; 能不能在两个事件中交错更新同一条记载呢?
不能！这不就是一个事件修改了另一个未提交事件修改过的数据，脏写。
InnoDB利用锁来保证不会有脏写环境的发生，也就是在第一个事件更新了某条记载后，就会给这条记载加锁，另一个事件再次更新时就必要等待第一个事件提交了，把锁释放之后才可以继续更新。
InnoDB增删改默认加x锁，查默认不加锁
每次对记载举行改动，都会记载一条undo日志，每条undo日志也都有一个roll_pointer属性（INSERT利用对应的undo日志没有该属性，因为该记载并没有更早的版本)，可以将这些undo日志都连起来，串成一个链表:
update写的时间是默认加了X锁的,20会等待10
https://i-blog.csdnimg.cn/blog_migrate/db433193eb3d46a156059ddcdb5b6e63.png
对该记载每次更新后，都会将旧值放到一条undo日志中，就算是该记载的一个旧版本，随着更新次数的增多，全部的版本都会被roll_pointer属性毗连成一个链表，把这个链表称之为版本链，版本链的头节点就是当前记载最新的值。
每个版本中还包含生成该版本时对应的事件id。
4. MVCC实现原理之ReadView
MVCC 的实现依赖于：隐蔽字段、Undo Log、Read View
4.1 什么是ReadView
在MVCC机制中，多个事件对同一个行记载举行更新会产生多个历史快照，这些历史快照生存在Undo Log里。如果一个事件想要查询这个行记载，必要读取哪个版本的行记载呢？这时就必要用到ReadView了，它办理了行的可见性问题
ReadView就是事件A在利用MVCC机制举行快照读利用时产生的读视图。当事件启动时，会生成数据库系统当前的一个快照，InnoDB为每个事件构造了一个数组，用来记载并维护系统当前活跃事件的ID（“活跃"指的就是，启动了但还没提交)
ReadView和事件是一对一的关系~ 也就是当事件中利用MVVC，且是Select时会生成一个ReadView~
4.2 设计思绪
利用READ UNCONNMITTED隔离级别的事件，由于可以读到未提交事件修改过的记载，所以直接读取的记载就是最新版本了。
利用SERIALIZABLE隔离级别的事件，InnoDB规定利用加锁的方式来访问记载。
利用 READ COMMITTED 和 REPEATABLE READ 隔离级别的事件，都必须保证读到 已经提交了的 事件修改过的记载。假如另一个事件已经修改了记载但是尚未提交，是不能直接读取最新版本的记载的，核心问题就是必要判定一下版本链中的哪个版本是当前事件可见的，这是ReadView要办理的主要问题。
这个ReadView中主要包含4个比较紧张的内容，分别如下：
[*] creator_trx_id ，创建这个 Read View 的事件 ID。
说明：只有在对表中的记载做改动时（实行INSERT、DELETE、UPDATE这些语句时）才会为事件分配事件id，否则在一个只读事件中的事件id值都默认为0。
[*] trx_ids ，表示在生成ReadView时当前系统中活跃的读写事件的 事件id列表 。
[*] up_limit_id ，活跃的事件中最小的事件 ID。
[*] low_limit_id ，表示生成ReadView时系统中应该分配给下一个事件的 id 值。low_limit_id 是系统最大的事件id值，这里要注意是系统中的事件id，必要区别于正在活跃的事件ID。
注意：low_limit_id并不是trx_ids中的最大值，事件id是递增分配的。好比，如今有id为1，2，3这三个事件，之后id为3的事件提交了。那么一个新的读事件在生成ReadView时，trx_ids就包括1和2，up_limit_id的值就是1，low_limit_id的值就是4。
举例：
trx_ids为trx2、trx3、trx5和trx8的集合，系统的最大事件ID (low_limit_id)为trx8+1(如果之前没有其他的新增事件)，活跃的最小事件ID (up_limit_id)为trx2。
https://i-blog.csdnimg.cn/blog_migrate/dae8dbfd5fb717421cf61192f663cd6e.png
4.3 ReadView的规则
有了这个ReadView，如许在访问某条记载时，只必要按照下边的步骤判定记载的某个版本是否可见。
[*]如果被访问版本的trx_id属性值与ReadView中的creator_trx_id 值类似，意味着当前事件在访问它自己修改过的记载，所以该版本可以被当前事件访问。
[*]如果被访问版本的trx_id属性值小于ReadView中的up_limit_id值，表明生成该版本的事件在当前事件生成ReadView前已经提交，所以该版本可以被当前事件访问。
[*]如果被访问版本的trx_id属性值大于或等于ReadView中的low_limit_id值，表明生成该版本的事件在当前事件生成ReadView后才开启，所以该版本不可以被当前事件访问。(否则会出现脏读)
[*]如果被访问版本的trx_id属性值在ReadView的up_limit_id 和low_limit_id之间，那就必要判定一下trx_id属性值是不是在trx_ids 列表中。
[*]如果在，说明创建ReadView时生成该版本的事件还是活跃的，该版本不可以被访问
[*]如果不在，说明创建ReadView时生成该版本的事件已经被提交，该版本可以被访问。
4.4 MVCC整体利用流程
相识了这些概念之后，来看下当查询一条记载的时间，系统如何通过MVCC找到它：
[*]首先获取事件自己的版本号，也就是事件 ID；
[*]获取(生成) ReadView；
[*]查询得到的数据，然后与 ReadView 中的事件版本号举行比较；
[*]如果不符合 ReadView 规则（当前版本不能被访问），就必要从 Undo Log 中获取历史快照；
[*]最后返回符合规则的数据。
如果某个版本的数据对当前事件不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判定可见性，依此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记载对该事件完全不可见，查询效果就不包含该记载。
InnoDB中，MVCC是通过Undo Log + Read View举行数据读取，Undo Log生存了历史快照，而Read View规则帮我们判定当前版本的数据是否可见。
Read View和事件是一对一对应的，而且Read View也是一个动态，不断变化的~
在隔离级别为读已提交（Read Committed）时，一个事件中的每一次 SELECT 查询都会重新获取一次Read View。
事件说明begin;select * from student where id >2;获取一次Read View…select * from student where id >2;获取一次Read Viewcommit; 注意，此时同样的查询语句都会重新获取一次Read View，这时如果Read View 差别，就可能产生不可重复读或者幻读的环境。如许符合Read Committed的规则特点~
当隔离级别为可重复读的时间，就制止了不可重复读，这是因为一个事件只在第一次SELECT的时间会获取一次Read View，而背面全部的SELECT都会复用这个Read View，如下表所示:
https://i-blog.csdnimg.cn/blog_migrate/d931d09fcdc22403a8dd83516db17bb6.png
5. 举例说明
假设如今student表中只有一条由事件id为8的事件插入的一条记载:
SELECT * FROM student ;
/*
+----+--------+--------+
| id | name | class|
+----+--------+--------+
|1 | 张三 | 一班 |
+----+--------+--------+
1 row in set (0.07 sec)
*/
MVCC只能在READ COMMITTED和REPEATABLE READ两个隔离级别下工作。接下来看一下READ COMMITTED和REPEATABLE READ所谓的生成ReadView的时机差别到底差别在那里
关于差别隔离级别下Read View的事件id,可以概括如下:
对于RC隔离级别:
[*]在一个事件中，每次查询会创建id为0的Read View。
[*]一旦有修改利用,会切换到以当前事件id为creator_trx_id的新Read View。
对于RR隔离级别:
[*]在一个事件中，只有第一次的查询会创建一个Read View。
[*]这个Read View的creator_trx_id就是当前事件的id。
RR要求整个事件的查询都要一致，所以只有第一次查询才会生成一个Read View。
而RC可以在同一事件内读取差别版本的数据，所以每次修改和查询都会生成新的Read View。
5.1 READ COMMITTED隔离级别下
READ COMMITTED ：每次读取数据前都生成一个ReadView
如今有两个 事件id 分别为 10 、 20 的事件在实行
# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
# Transaction 20
BEGIN;
# 更新了一些别的表的记录(为了分配事务id)
...
说明:事件实行过程中，只有在第一次真正修改记载时(好比利用INSERT、DELETE、UPDATE语句)，才会被分配一个单独的事件id，这个事件id是递增的。所以我们才在事件2中更新一些别的表的记载，目的是让它分配事件id。
此刻，表student 中id为1的记载得到的版本链表如下所示：
https://i-blog.csdnimg.cn/blog_migrate/ac77b5602b5e2f804dc256ec97a3e02c.png
假设如今有一个利用 READ COMMITTED 隔离级别的事件开始实行：
# 使用READ COMMITTED隔离级别的事务
BEGIN;
# SELECT1：Transaction 10、20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
这个 SELECT1 的实行过程如下：
步骤1∶在实行SELECT语句时会老师成一个ReadView ，ReadView的trx_ids列表的内容就是,up_limit_id为10, low_limit_id为21, creator_trx_id为0。
步骤2：从版本链中挑选可见的记载，从图中看出，最新版本的列name的内容是’王五’，该版本的trx_id值为10，在trx_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本
步骤3：下一个版本的列name的内容是’李四’，该版本的trx_id值也为10，也在trx_ids列表内，所以也不符合要求，继续跳到下一个版本
步骤4：下一个版本的列name的内容是’张三’，该版本的trx_id值为8，小于ReadView中的up_limit_id值10，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为‘张三’的记载。
之后，把 事件id 为 10 的事件提交一下：
# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
COMMIT;
然后再到 事件id 为 20 的事件中更新一下表 student 中 id 为 1 的记载：
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
UPDATE student SET name="钱七" WHERE id=1;
UPDATE student SET name="宋八" WHERE id=1;
此刻，表student中 id 为 1 的记载的版本链就长如许：
https://i-blog.csdnimg.cn/blog_migrate/edf136b3d0af2b78cbf2dcdff31ff91f.png
然后再到刚才利用 READ COMMITTED 隔离级别的事件中继续查找这个 id为 1 的记载，如下：
# 使用READ COMMITTED隔离级别的事务
BEGIN;
# SELECT1：Transaction 10、20 均未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
# SELECT2：Transaction 10提交，Transaction 20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'王五'
这个SELECT2的实行过程如下:
步骤1：在实行SELECT语句时会又会单独生成一个ReadView，该ReadView的trx_ids列表的内容就是，up_limit_id为20，low_limit_id为21, creator_trx_id为0。
步骤2：从版本链中挑选可见的记载，从图中看出，最新版本的列name的内容是’宋八’，该版本的trx_id值为20，在trx_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
步骤3∶下一个版本的列name的内容是‘钱七’，该版本的trx_id值为20，也在trx_ids列表内，所以也不符合要求，继续跳到下一个版本
步骤4∶下一个版本的列name的内容是’王五’，该版本的trx_id值为10，小于ReadView中的up_limit_id值20，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为’王五’的记载。
以此类推，如果之后事件id为20的记载也提交了，再次在利用READ COMMITED 隔离级别的事件查询表student中id值为1的记载时，得到的效果就是’宋八’了，具体流程我们就不分析了。
夸大： 利用READ COMMITTED隔离级别的事件在每次查询开始时都会生成一个独立的ReadView
5.2 REPEATABLE READ隔离级别下
利用 REPEATABLE READ 隔离级别的事件来说，只会在第一次实行查询语句时生成一个 ReadView ，之后的查询就不会重复生成了。
好比，系统里有两个 事件id 分别为 10 、 20 的事件在实行：
# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
此刻，表student 中 id 为 1 的记载得到的版本链表如下所示：
https://i-blog.csdnimg.cn/blog_migrate/27412a6e194751bb11f1f250217765f7.png
假设如今有一个利用 REPEATABLE READ 隔离级别的事件开始实行：
# 使用REPEATABLE READ隔离级别的事务
BEGIN;
# SELECT1：Transaction 10、20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
这个SELECT1的实行过程如下:
步骤1：在实行SELECT语句时会老师成一个ReadView，ReadView的trx_ids列表的内容就是，up_limit_id为10, low_limit_id为21, creator_trx_id为0。
步骤2：然后从版本链中挑选可见的记载，从图中看出，最新版本的列name的内容是’王五’，该版本的trx_id值为10，在trx_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
步骤3：下一个版本的列name的内容是’李四’，该版本的trx_id值也为10，也在trx_ids列表内，所以也不符合要求，继续跳到下一个版本。
步骤4：下一个版本的列name的内容是’张三’，该版本的trx_id值为8，小于ReadView中的up_limit_id值10，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为’张三 ’的记载
之后，我们把事件id为10的事件提交一下，就像如许:
# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
COMMIT;
然后再到 事件id 为 20 的事件中更新一下表 student 中 id 为 1 的记载：
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
UPDATE student SET name="钱七" WHERE id=1;
UPDATE student SET name="宋八" WHERE id=1;
此刻，表student 中 id 为 1 的记载的版本链长如许：
https://i-blog.csdnimg.cn/blog_migrate/0b0cf055b8b184062c9376151c799923.png
然后再到刚才利用 REPEATABLE READ 隔离级别的事件中继续查找这个id 为 1 的记载，如下：
# 使用REPEATABLE READ隔离级别的事务
BEGIN;
# SELECT1：Transaction 10、20均未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
# SELECT2：Transaction 10提交，Transaction 20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值仍为'张三'
SELECT2的实行过程如下:
步骤1：因为当前事件的隔离级别为REPEATABLE READ，而之前在实行SELECT1时已经生成过ReadView了，所以此时直接复用之前的ReadView，之前的ReadView的trx_ids列表的内容就是，up_limit_id为10，low_limit_id为21, creator_trx_id为0。
步骤2：然后从版本链中挑选可见的记载，从图中可以看出，最新版本的列name的内容是’宋八’，该版本的trx_id值为20，在trx_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本
步骤3：下一个版本的列name的内容是’钱七’，该版本的trx_id值为20，也在trx_ids列表内，所以也不符合要求，继续跳到下一个版本
步骤4：下一个版本的列name的内容是’王五’，该版本的trx_id值为10，而trx_ids列表中是包含值为10的事件id的，所以该版本也不符合要求，同理下一个列name的内容是‘李四’的版本也不符合要求。继续跳到下一个版本
步骤5：下一个版本的列name的内容是’张三’，该版本的trx_id值为8，小于ReadView中的up_limit_id值10，所以这个版本是符合要求的，最后返回给用户的版本就是这条列c为‘张三’的记载。
两次SELECT查询得到的效果是重复的，记载的列c值都是‘张三’，这就是可重复读的含义。如果我们之后再把事件id为20的记载提交了，然后再到刚才利用REPEATABLE READ隔离级别的事件中继续查找这个id为1的记得到的效果还是‘张三’，具体实行过程大家可以自己分析一下。
5.3 如何办理幻读
接下来说明InnoDB 是如何办理幻读的。
假设如今表 student 中只有一条数据，数据内容中，主键 id=1，隐蔽的 trx_id=10，它的 undo log 如下图所示。
https://i-blog.csdnimg.cn/blog_migrate/ab94270ecfb38c8625d8eb546b46b1ac.png
假设如今有事件 A 和事件 B 并发实行， 事件 A 的事件 id 为 20 ， 事件 B 的事件 id 为 30 。
步骤1：事件 A 开始第一次查询数据，查询的 SQL 语句如下
select * from student where id >= 1;
在开始查询之前，MySQL 会为事件 A 产生一个 ReadView，此时 ReadView 的内容如下： trx_ids= ，up_limit_id=20 ， low_limit_id=31 ， creator_trx_id=20 。
由于此时表 student 中只有一条数据，且符合 where id>=1 条件，因此会查询出来。然后根据 ReadView机制，发现该行数据的trx_id=10，小于事件 A 的 ReadView 里 up_limit_id，这表示这条数据是事件 A 开启之前，其他事件就已经提交了的数据，因此事件 A 可以读取到。
结论：事件 A 的第一次查询，能读取到一条数据，id=1。
步骤2：接着事件 B(trx_id=30)，往表 student 中新插入两条数据，并提交事件
insert into student(id,name) values(2,'李四');
insert into student(id,name) values(3,'王五');
此时表student 中就有三条数据了，对应的 undo 如下图所示：
https://i-blog.csdnimg.cn/blog_migrate/51a800b781662c6a5dc71a30b1f995e4.png
步骤3：接着事件 A 开启第二次查询，根据可重复读隔离级别的规则，此时事件 A 并不会再重新生成ReadView。此时表 student 中的 3 条数据都满意 where id>=1 的条件，因此会先查出来。然后根据ReadView 机制，判定每条数据是不是都可以被事件 A 看到。
1）首先 id=1 的这条数据，前面已经说过了，可以被事件 A 看到。
2）然后是 id=2 的数据，它的 trx_id=30，此时事件 A 发现，这个值处于 up_limit_id 和 low_limit_id 之间，因此还必要再判定 30 是否处于 trx_ids 数组内。由于事件 A 的 trx_ids=，因此在数组内，这表示 id=2 的这条数据是与事件 A 在同一时候启动的其他事件提交的，所以这条数据不能让事件 A 看到
3）同理，id=3 的这条数据，trx_id 也为 30，因此也不能被事件 A 看见
https://i-blog.csdnimg.cn/blog_migrate/79e46151fb366bddd04a766567bbbb54.png
结论：最终事件 A 的第二次查询，只能查询出 id=1 的这条数据。这和事件 A 的第一次查询的效果是一样的，因此没有出现幻读征象，所以说在 MySQL 的可重复读隔离级别下，不存在幻读问题。
6. 总结
这里先容了 MVCC 在 READ COMMITTD 、 REPEATABLE READ 这两种隔离级别的事件在实行快照读利用时访问记载的版本链的过程。如许使差别事件的 读-写 、 写-读 利用并发实行，从而提升系统性能
核心点在于 ReadView 的原理， READ COMMITTD 、 REPEATABLE READ 这两个隔离级别的一个很大差别就是生成ReadView的时机差别：
[*] READ COMMITTD 在每一次举行普通SELECT利用前都会生成一个ReadView
[*] REPEATABLE READ只在第一次举行普通SELECT利用前生成一个ReadView，之后的查询利用都重复利用这个ReadView就好了
说明：之前说实行DELETE语句或者更新主键的UPDATE语句并不会立刻把对应的记载完全从页面中删除，而是实行一个所谓的delete mark利用(标记0->1)，相当于只是对记载打上了一个删除标志位，这主要就是为MVCC服务的。另外背面回滚也可能用到这个delete mark~
通过 MVCC 可以办理:
[*] 读写之间壅闭的问题。通过MVCC 可以让读写相互不壅闭，即读不壅闭写，写不壅闭读，如许就可以提升事件并发处理本领
[*] 降低了死锁的概率。这是因为MVCC采用了乐观锁的方式，读取数据时并不必要加锁，对于写利用，也只锁 定必要的行
[*] 办理快照读的问题。当查询数据库在某个时间点的快照时，只能看到这个时间点之前事件提交更新的效果，而不能看到这个时间点之后事件提交的更新效果
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]