4.15 公众号《架构师》总结——MySQL主从延时这么长，要怎么优化？

MySQL主从复制和读写分离是常见的数据库架构，但在高并发、大数据量的场景下，主从延时问题较为突出。
主从延时的原因
MySQL主从复制的延时主要源于从库使用单线程重放RelayLog，这导致重放速度较慢。
优化方法
多线程并行重放RelayLog：通过多线程并行重放RelayLog可以缩短重放时间。
分割RelayLog：需要合理分割RelayLog，确保多个线程并行重放时不会出现数据不一致。
数据不一致的原因
如果RelayLog随机分配给不同的重放线程，可能导致事务执行顺序与主库不一致，最终导致从库数据与主库不一致。
解决方案
按库分配线程：相同库上的写操作由相同线程重放，不同库上的写操作可以并行重放。
哈希算法：通过设计哈希算法（如hash(db-name) % thread-num），确保同一个库的写操作由同一个线程串行执行，不同库的写操作并行执行。
方案的不足
对于“单库多表”的架构，即使使用多线程并行重放，仍然无法提高RelayLog的重放速度。
启示
将“单库多表”架构升级为“多库多表”架构，不仅可以提高RelayLog的重放速度，还具备以下优势：
方便实例扩展。
按业务进行库隔离，减少耦合。
便于微服务拆分。
单库多表的优化思路
即使只有一个库，事务在主库上是并发执行的，从库上也应该能够并行执行。基于GTID的并行复制可以实现这一目标。
基于GTID的并行复制
从MySQL 5.7开始，组提交的信息被存放在GTID中，通过last_committed和sequence_number标识事务组。具有相同last_committed的事务可以并发回放。