**MVCC的缺点：**

MVCC在大多数情况下代替了行锁，实现了对读的非阻塞，读不加锁，读写不冲突。缺点是每行记录**都需要额外的存储空间，需要做更多的行维护和检查工作**。 要知道的，MVCC机制下，会在更新前建立undo log，根据各种策略读取时非阻塞就是MVCC，undo log中的行就是MVCC中的多版本。 而undo log这个关键的东西，**记载的内容是串行化的结果，记录了多个事务的过程，不属于多版本共存**。 这么一看，似乎mysql的mvcc也并没有所谓的多版本共存

**读写分离原理**：

主库（master）将变更写**binlog**日志，然后从库（slave）连接到主库之后，从库有一个**IO线程**，将主库的binlog日志**拷贝到自己本地**，写入一个中继日志中。接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容，也就是在自己本地再次执行一遍SQL，这样就可以保证自己跟主库的数据是一样的。

这里有一个非常重要的一点，就是从库同步主库数据的过程是**串行化**的，也就是说**主库上并行**的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行SQL的特点，在高并发场景下，从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。

而且这里还有另外一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。

所以mysql实际上在这一块有两个机制，一个是**半同步复制**，用来解决主库数据丢失问题；一个是**并行复制**，用来解决主从同步延时问题。

所谓并行复制，指的是从库**开启多个线程，并行读取relay log中不同库的日志**，然后并行重放不同库的日志，这是库级别的并行。