MySQL复制单线程瓶颈的演进：从库级并行到基于逻辑时间戳的并行

MySQL原生复制长期被诟病的一个核心问题是单线程回放——从库应用主库传来的binlog时，早期版本只能用单个线程按顺序依次执行，这直接导致了主从延时问题：即使从库硬件性能很强，单线程的处理速度也很容易跟不上主库多线程并发写入产生的binlog量，成为主从延时的重要根源。MySQL 5.6版本给出了第一版官方并行复制方案，但这版方案的并行粒度是”库级别”的——只有当同一个MySQL实例下有多个独立的数据库（schema）时，不同库之间的binlog应用才能并行执行，如果整个实例只有一个库，这个并行复制方案基本没有意义，因为所有变更依然要在这一个库的维度上串行处理。MySQL团队意识到了这个瓶颈，在5.7版本引入了新的并行复制方式，基于logical timestamp（逻辑时间戳）——这种方式不再受限于”必须有多个库才能并行”这个前提，理论上能够识别出binlog事件之间真正的依赖关系（哪些事件互相独立、可以安全并行执行），从而在单库场景下也能实现有效的并行回放，效率相比5.6版本的库级并行有大幅提升。这个演进路径提示了一条评估”并行化方案是否真正解决问题”的重要经验：一个标榜”支持并行”的方案，需要具体审视它并行化的粒度和适用边界——5.6版本的库级并行，对于当下互联网公司普遍采用的”单库多表、甚至单库架构”这类场景，实际收益非常有限，看似解决了问题，实际上只是把问题的适用范围限定在了一个相对少见的场景里；只有当并行化的粒度真正贴合了实际负载的特征（这里是能识别单库内部事件间的真实依赖关系），这个方案才算是真正意义上解决了原本的瓶颈。