1、MVCC
- 简单讲讲你对 MVCC 的理解。
MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，做到非阻塞并发读。
- MVCC多版本并发控制的原理
通过undo_log多版本链条，加上开启事务时产生的readView（不同隔离级别有不同产生策略）,然后再有一个查询的时候,根据readView进行判断的机制，来决定读取哪个版本的数据。实现了多事务并发执行，保证只能读开启事务前提交的数据和当前事务修改的数据，其他情况都不会读到。
也就是说，不管事务执行多长时间，事务内部看到的数据是不受其它事务影响的，根据事务开始的时间不同，不同事务对同一张表，同一时刻看到的数据可能是不一样的。
MVCC实现
隐式字段
在表中，除了我们自定义的列，实际上MySQL会隐式的定义三个字段
DB_TRX_ID：事务ID，创建这条记录/最后一次修改该记录的事务IDDB_ROLL_PTR：回滚指针，指向这条记录的上一个版本DB_ROW_ID：隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID`产生一个聚簇索引
undo_log 日志版本链
undo_log 版本链是指一行数据被多个事务依次修改过后，在每个事务修改完后，Mysql会保留修改前的数据undo回滚日志，并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链
insert undo log：代表事务在insert新纪录时产生的undo_log，只在事务回滚时需要，并且在事务提交后可以被立即抛弃。
update undo log：事务在update或者delete时产生的undo log，不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只要在快速读或者事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除。
Read View
Read View是事务进行快照读操作时产生的读视图(RV),在该事务执行快照读的那一刻，会生成数据库系统的当前的一个快照，记录并维护当前活跃事务的ID(当每个事务开启时，都会被分配一个ID，这个ID是自增的，所以最新的事务，ID值越大)
RV主要是用来做可见行判断的，即当我们某个事务执行快照读的时候，对该记录创建一个RV读视图，把它比作条件来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。
RV遵循一个可见性算法，主要是将要被修改的数据的最新记录的DB_TRX_ID(即当前事务ID),与系统当前其他活跃事务的ID去对比(由RV维护)，如果DB_TRX_ID跟RV的属性做了某些对比，不符合可见性，那么就由DB_ROLL_PTR回滚指针去取出undo log中的DB_TRX_ID再比较，即遍历链表的DB_TRX_ID(从链表头到尾，即从最近的一次修改查起)，直到找到满足特定条件的DB_TRX_ID，那么这个DB_TRX_ID所在的旧记录就是当前事务能看见的最新老版本
实现流程
事务隔离级别与MVCC的关系
- REPEATABLE READ（可重复读） REPEATABLE READ级别会使用MVCC，只有在第一次进行快照读会生成read view，之后的快照读都会沿用第一次生成的read view，所以每次快照读读到的数据都是一样的，这样就可以解决脏读问题以及快照读的不可重复读、幻读问题。
这就是上面说的，只能读开启事务前提交的数据和当前事务修改的数据，其他情况都不会读到。
当前读与快照读
- 当前读
像select lock in share mode(共享锁); select for update, update，delete，insert(排它锁)这些操作就是一种当前读，因为它读取的是数据的最新版本，读取时还要保证其他事务不能修改当前记录，会对记录进行加锁。
- 快照读
不加锁的select就是快照读，即不加锁的非阻塞读；(快照读的前提是隔离级别不是串行化，串行化的隔离级别下快照读会退化成当前读) 之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC，可以认为MVCC是行锁的一个变种，但是它在很多情况下避免了加锁操作，降低了开销，既然是基于多版本，所以快照读可能读到的不一定是数据的最新版本，而有可能是之前的历史版本
2、Mysql主从复制三大模式
sync :全同步
当主库执行完一个事务，所有的从库都执行了该事务才会将结果返回给客户端。这样保证了数据的安全性，但是因为需要等待所有从库执行完该事务才能返回客户端结果，所以全同步复制的性能必然会受到很大的影响。
对于全同步复制而言，当主库提交一个事务后，要求所有从库节点必须收到，执行并提交这些事务，然后主库线程才能继续做后续操作，而因此带来的问题就是主库完成一个事务的时间被大幅度拉长，性能降低。
async : 异步
主库在执行完客户端提交的事务后会立刻将执行结果返回给客户端，并不关心从库是否已经接收处理，这样带来的问题就是当主死掉了，此时主上提交的事务可能还没有传到从上。而强行将从提升为主就会导致新主上的数据不完整。
semi-sync : 半同步
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时也会造成一定程度的延迟，这个延迟为一个TCP/IP往返的时间。所以半同步复制需要在低延时的网络中使用。
对于半同步复制而言，是介于同步复制和异步复制之间的一种，主库需要等待至少一个从库节点收到并且刷新binlog到relay日志中，主库不需要等待所有从库给主库反馈，同时这里只是收到反馈而不死和完全执行并且提交事务的反馈，这样会节省很多的时间。
总结：实际业务中，一般都是配置使用半同步的，全同步高并发下有性能问题，异步有数据丢失的可能，所以，还是使用半同步。
