深入理解MVCC与Buffer Pool缓存机制

一、MVCC多版本并发控制机制

首先来重新认识一下可重复读和串行化：
可重复读：mysql的默认隔离级别是可重复读，也就是在一个事务中，多次查询结果都相同。就算有其他事务修改了数据，也不会影响当前事务的查询结果。读操作不加锁，使用mvcc机制
串行化：读和写操作也加行锁，其他事务的所有读写操作都会被阻塞。
可重复读和串行化其实都是为了保证多次读到的数据一致，确保了隔离性。如果没有隔离性保障，那当其他事务修改数据时，java代码中的数据就在不断变化，就无法写代码了。
可重复读的这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的，对一行数据的读操作默认是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥。而在串行化隔离级别为了保证较高的隔离性是通过将所有操作加锁互斥来实现的，频繁加锁导致效率低下！

二、MVCC机制底层是怎么实现的–怎么保证可重复读的呢？

mvcc机制就是靠undo日志版本链和一致性视图read-view来实现的。

undo日志版本链与read view机制详解
undo日志版本链是指在多事务的情况下，多个事务对同一行数据进行修改，Mysql会通过一个日志版本链来记录旧的数据，如果事务未提交之前发生了回滚操作则可以回滚到原来的数据。
undo日志版本链通过trx_id和roll_pointer两个属性来维护的。

在可重复读隔离级别下，当一个事务第一次执行读操作的时候，Mysql会为该事务生成一致性事务。该视图由两部分组成。一部分是当前最大的事务id和未提交事务id组构成。并且将未提交事务组中事务id最小的记为min_id,最大的事务id记为max_id。事务的任何sql都要从日志版本链中从最新的一条数据依次跟read-view进行比较从而得到快照的结果。

版本链比对规则：

1. 如果 row 的 trx_id 落在绿色部分(trx_id < max_id)，表示这个版本是由已经提交的事务生成的，是可见的。
2. 如果 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由将来启动的事务生成的，是不可见的(若 row 的 trx_id 就是当前自己的事务是可见的）；
3. 如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)，那就包括两种情况
   a. 若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx_id 就是当前自己的事务是可见的)；
   b. 若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。
   如下图所示：
   
   对于删除的情况可以认为是update的特殊情况，会将版本链上最新的数据复制一份，然后将trx_id修改成删除操作的trx_id，同时在该条记录的头信息（record header）里的（deleted_flag）标记位写上true，来表示当前记录已经被删除，在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true，意味着记录已被删除，则不返回数据。
   
   注意：
   begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个修改操作InnoDB表的语句，事务才真正启动，才会向mysql申请事务id，mysql内部是严格按照事务的启动顺序来分配事务id的。

小总结一下：mvcc机制通过undo日志版本链 + read-view机制实现了不同事务在同一个日志版本链中读取不同的数据记录。

面试题：InnoDB的RR级别下怎么实现可重复读？底层实现原理？MCVV机制的快照读怎么实现的？
就是我们上面说的内容：mvcc机制–undo日志版本链 + read-view机制

MVCC锁相关

在MVCC中，读操作可以分成：快照读 (snapshot read)与当前读 (current read)。

快照读： 读取的是记录的可见版本，不加锁。
当前读： 读取的是记录的最新版本，并且会对读取的记录加上锁（有共享和排他锁），确保其他事务不会并发地修改这条记录。

快照读：简单的select操作属于快照读，不会加锁。 select * from table where id=1;

当前读：添加了关键字的特殊查询操作，或者update、delete、insert都属于当前读，需要加锁。这里的锁分为共享锁和排他锁。
select * from table where ? lock in share mode;
select * from table where ? for update;
insert into table values (…);
update table set ? where ?;
delete from table where ?;
以上语句中除了第一条是共享锁（S锁），其他都是排他锁（X锁）

为什么增删改也是当前读？ 因为要进行增删改之前都得先找到符合条件的行，找的过程不就是读嘛~为了保证数据的线程安全性，需要对当前行进行加锁，有时也会出现锁表。
lock in share mode和for update有何区别？

1）前者为记录添加的是S锁，后者添加的是X锁。共享锁和快照锁都不会影响快照读。
2）根据S锁和X锁的规则，当记录中有S锁时，其他事务允许快照读，或再添加一个S锁，但是不允许添加X锁，必须等所有S锁都被释放以后才能上X锁。
3）当记录中有X锁时，只允许快照读，不允许再添加X锁和S锁，直到该X锁释放（事务commit）。

MVCC机制的作用？

如果没有MVCC机制，当一个事务对表中某行数据进行写操作。此时当这个事务未提交之前，其他事务不能对该行数据执行读和写操作。这样Mysql的效率就很低啊。所以使用MVCC机制。当有事务在对某一行数据进行修改时，其他事务依然可以对该行记录进行快照读。这样就实现了读和写不冲突。实际上对于写操作还是加了锁的，只是这个锁并不影响其他事务的读，但是不能执行写操作。MVCC并没有解决幻读的现象，Mysql允许幻读现象的存在的。可以使用间隙锁解决一部分的幻读现象。

Buffer Pool缓存池

为什么Mysql不能直接更新磁盘上的数据而且设置这么一套复杂的机制来执行SQL了？
性能和数据完整性两个方面：
如果来一条数据就进行一次磁盘的写入，也就意味着一次I/O操作。显然效率是不高的，Mysql就扛不住高并发的场景。如果每次都将数据写入到buffer pool中是在内存中执行的，速度很快。在写入buffer pool的同时，会维护undo日志、redo日志以及bin-log日志。虽然要维护三张表，但由于读写都顺序读写的并且读取数据在内存中进行，所以要比随机读写的效率更高。这让mysql可以抗住高并发的。Mysql会有一个I/O线程每隔一段时间将buffer pool中的数据以页为单位随机写入磁盘中。
mysql这些复杂的机制还有一个作用就是保证数据的一致性和完整性。
undo日志：事务回滚时可以恢复到原来的数据
redo日志：如果buffer pool中的数据还没写入到磁盘中时mysql宕机了。当再次启动mysql时会根据redo日志来恢复buffer pool中的数据
bin-log日志：如果磁盘中的数据丢失的话，可以通过bin-log日志来恢复