公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2017-03-21 23:16:13 · 原文链接

  昨天花了点时间整理了下并行复制在5.6,5.7中的一些差别和测试，MySQL 5.6, 5.7并行复制测试(r12笔记第9天),当然只是一个开始，因为里面还有不少需要完善的部分，总体的感觉来看MySQL 5.7里的并行复制改进很大，能够极大提高效率，充分利用资源。

  那我们来简单回顾一下MySQL的复制里的一些事情，然后继续展开测试。

   首先借丁奇大师总结的一个经典的主从复制的流程图来展开。

整个复制的流程中，看似存在多个节点会存在延迟的可能，而如果把这些工作都细化，那么就会有一个很本质的原因，那就是在主库端的更新是多线程，而从库端更新是单线程。

   这样一个看似“存在即合理”方案在MySQL 5.6以前都是这么做的。最早的复制和statement格式做斗争，过了改进，有了row格式，也算是复制方向上的一大改进，而在MySQL 5.6中引入了并行复制，这一点能够缓和原本的复制瓶颈。

    但是复制的效率提升不是严格意义上质的飞跃，算是一个开篇，因为支持的是数据库级别的，如果直接多线程是否可以，这个按理说是一个很常规的思路，为什么MySQL迟迟没有推出好的方案来。

   多线程存在一些待解决的难题，其中之一就是语句的顺序无法保证，无论如何，日志都是需要顺序写，在源端是多线程并发操作，而映射到日志中，必然是一个顺序的记录方式，而这个操作到了从库，也只能老老实实的按照顺序来应用，如果采用多线程就得尤其注意这个顺序，我们可以逐步来细分，首先对于同一个表的更新只能按照顺序来同步，而这个粒度可以逐步细分，比如数据库级，表级等，目前MySQL 5.6中是按照数据库级来做的，当然这个粒度还是有些粗。在5.7就全面改进了。

   当然我们在开始具体的测试之前，我简单说一下我们量血压的场景，一般都会有一个收缩压，舒张压的指标，对于主从复制而言，我突然想到了这一点，我觉得还是有可以借鉴的地方。

    比如我昨天测试的而一个图，是MySQL 5,6,5.7单线程，多线程的延迟对比图。