Mysql进阶（二)：MVCC详解
Mysql进阶（二）：MVCC详解
-
- MVCC是什么？
- MVCC 解决了什么问题？
-
- 什么是当前读,快照读？
- 什么是Redo log, Bin log, Undo log
-
- Undo log 他是干什么的？为什么需要它？
- Readview
MVCC是什么？
MVCC是多版本控制器，就是在同一时间内，不同的事务可以读取到不同的版本。用这样的方法解决脏读和不可重复的问题。
定义：
InnoDB通过为每一行记录添加两个额外的隐藏的值来实现MVCC，
- DB_TRX_ID：
记录这行数据何时被创建，插入或更新该行的最后一个事务的事务 ID - DB_ROLL_PTR：
记录指向上一个版本，回滚操作就是通过这个字段进行的，假如现在有一个insert操作，他就会有一个相反的delete操作，如果事务运行到insert后，出错了，他就会通过这个字段回滚，执行相反的delete。
事物的ID是自增的，InnoDB并不存储这些事件发生时的实际时间，相反它只存储这些事件发生时的系统版本号（LSN）。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。
MVCC实现原理是由俩个隐式字段、undo日志、Read view来实现的。
MVCC 解决了什么问题？
多版本并发控制（MVCC）是一种用来解决读-写冲突的无锁并发控制，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能 。mvcc可以解决脏读，不可重复读，mvcc使用快照读解决了部分幻读问题，一旦在事务中使用了当前读，那么这个时候就是当前读。因为在在当前读MVCC解决不了幻读问题，所以还是存在幻读问题，幻读问题最终就是使用间隙锁解决。
什么是当前读,快照读？
- 当前读： 当前读, 读取的是最新版本, 但是读的时候不允许写，写的时候也不允许读，并且对读取的记录加锁, 阻塞其他事务同时改动相同记录，避免出现安全问题，下面的操作都是当前读，不加锁的都是快照读。
select...lock in share mode (共享读锁)
select...for update
update , delete , insert
例如，假设要update一条记录，但是另一个事务已经delete这条数据并且commit了，如果不加锁就会产生冲突。所以update的时候肯定要是当前读，得到最新的信息并且锁定相应的记录
2. 快照读：读写不冲突，每次读取的是快照数据，MVCC只在下面的两个级别适用：
Repeatable Read下（默认隔离级别）：有可能读取的不是最新的数据
Read Committed隔离级别下：快照读和当前读读取的数据是一样的，都是最新的。
快照读他解决了同时读写不阻塞，提高了性能。但是版本生成了很多个，我怎么知道我应该访问那个版本呢?答案是：read-view，后面我将会讲解。
在快照读隔离级别下，事务在开始时创建一个快照，该快照包含了事务开始时数据库中的所有数据。事务在整个事务期间都使用这个快照，而不受其他事务的影响。这意味着事务在整个过程中看到的数据是一致的，即使其他事务在此期间对数据进行了修改。快照读可以防止脏读和不可重复读，但仍然允许幻读的发生。
什么是Redo log, Bin log, Undo log
这节我们主要讲解和MVCC相关的undo log ，其他两个日志会在下个文章中讲解
undo log（回滚日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。
redo log（重做日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复；
binlog （归档日志）：是 Server 层生成的日志，主要用于数据备份和主从复制；
Undo log 他是干什么的？为什么需要它？
我在上一节讲过mysql会自己隐形的开启事务，当他执行update，insert，delete 语句的时候会自动的开启提交事务，所以在我们执行update语句的时候，他是用到事务的， autocommit 参数控制是否自动提交事务，0为手动提交，1为自动提交。但是如果在执行update语句的时候，mysql系统宕机了，那么我们的数据是不是就不一致了，此时我怎么回到之前的数据呢？ 如果我们在执行事务之前，在日志中都记录下回滚所需要的信息，如果系统发生宕机，我就把日志中所需要的内容进行回滚，这就保证了事务的ACID特性即为（原子性）。
我们每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个roll_pointer属性（insert操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表。
对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本。随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。
版本链会无限增长吗？不会！如果undo log一直不删除，则会通过当前记录的回滚指针回溯到该行创建时的初始内容。所幸的是在Innodb中存在purge线程，它会查询那些比现在最老的活动事务还早的undo log，并删除它们，从而保证undo log文件不至于无限增长。
他的roll_pointer 是指向的上一个修改的版本
作用一：事务回滚
每次的update，insert，delete操作的时候，都需要把回滚的信息存储到undo log 中，下面是回滚的列子
- 在insert的时候，要把这个insert的主键记录下来，如果系统宕机，那么我在回滚的时候就删除对应的主键就行了；
- 在delete的时候，要把这个dele的内容记录下来，如果系统宕机，那么我在回滚的时候就插入对应的内容就行了；
- 在update的时候，要把更新的列旧值记录下来，如果系统宕机，那么我在回滚的时候就更新对应的旧值就行了
作用二：崩溃恢复
在InnoDB因为某些原因停止运行后；重启InnoDB时，可能存在一个不一致的状态，这个时候我们就需要把MySQL恢复到一个一致的状态来保证数据库的可用性。这个恢复过程主要分下面这么几步：
5. 把最新的undo log从redo log中恢复出来，因为undo log是受redo log保护的。
6. 根据最新的undo log构建出InnoDB崩溃前的状态。
7. 回滚那些还没有提交的事务。
经过上面这三步后，InnoDB就可以恢复到一个一致的状态，并且对外提供服务。
说白了在发生回滚的时候，就会读取undo log 的日志，然后做相反的操作，当我执行删除的语句，回滚时执行插入的语句，当我执行插入的语句，回滚时就执行删除的语句。不同的操作类型产生的日志也是不一样的。undo 就是记录的各个时间点所对应的版本，
作用三: 多版本控制(mvcc)
多版本并发控制简单的说就是当前事务只能看见已经提交的数据记录，看不到正在修改的数据记录。所以我们只要弄清楚哪些事务对于当前事务是已经提交的，哪些事务对于当前事务是活跃的。通过undo log 的版本链 以及readview 能控制事务访问的版本就能做到多版本控制。下面将介绍怎么通过readview来控制版本链的
Readview
-
什么是Readview？
在MVCC机制中，多个事务对同一个行记录进行更新会产生多个历史快照，这些历史快照保存在undo log里，如果一个事务想要查询查询这个行记录，需要读取哪个版本的历史记录呢？这时就需要用到ReadView了，它帮我们解决了行的可见性问题。
ReadView就是事务在使用MVCC机制进行快照读操作时产生的读视图。当事务启动时，会生成数据库系统当前的一个快照，InnoDB为每个事务构造了一个数组，用来记录并维护系统当前活跃事务的ID（"活跃"指的就是，启动了但还没提交）下面是Readview的常用字段
creator_trx_id，创建这个ReadView的事务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。 -
Readview 匹配规则
如果被访问版本的 trx_id，与 Readview 中的 creator_trx_id 值相同，表明当前事务在访问自己修改过的记录，该版本可以被当前事务访问；
如果被访问版本的 trx_id，小于 Readview 中的 min_trx_id 值，表明生成该版本的事务在当前事务生成 Readview 前已经提交，该版本可以被当前事务访问；
如果被访问版本的 trx_id，大于等于 Readview 中的 min_trx_id 值，且 trx_id 值在 m_ids 之中，表明生成该版本的事务在当前事务生成 Readview 时仍在执行中，该版本不可被当前事务访问；
如果被访问版本的 trx_id，大于等于 Readview 中的 min_trx_id 值，且 trx_id 值不在 m_ids 之中，表明生成该版本的事务在当前事务生成 Readview 后才开始执行，该版本不可被当前事务访问 -
MIVCC整体的操作流程
首先获取事务自己的版本号，也就是事务id；
获取ReadView
查询得到的数据，然后与ReadView中的事务版本号进行比较
如果不符合ReadView规则，就需要从Undo log中获取历史快照；
最后返回符合规则的数据。
如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性。以此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对该事务完全不可见，查询结果就不包含该记录。
InnoDB中，MVCC是通过Undo Log + ReadView进行数据读取，Undo Log保存了历史快照，而ReadView规则帮我们判断当前版本的数据是否可见。
在隔离级别为读已提交（Read Commit）时，一个事务中的每一次select查询都会重新获取一次Read View，所以他能读取到最新提交的数据。当隔离级别为可重复读的时候，就避免了不可重复读，这时因为一个事务只在第一次select的时候会获取一次ReadView，而后面所有的select都会复用这个ReadView
通过MVCC我们可以解决：
读写之间阻塞的问题。通过MVCC可以让读写互相不阻塞，即读不阻塞写，写不阻塞读，这样就可以提升事务并发处理能力。
降低了死锁的概率。这是因为MVCC采用了乐观锁的方式，读取数据时并不需要加锁，对于写操作也只锁定必要的行。
解决快照读的问题。当我们查询数据库在某个时间点的快照时，只能看到这个时间点之前事务提交更新的结果，而不能看到这个时间点之后事务提交的更新结果。