本文主要给大家介绍MySQL主从延迟问题应该如何解决，文章内容都是笔者用心摘选和编辑的，具有一定的针对性，对大家的参考意义还是比较大的，下面跟笔者一起了解下MySQL主从延迟问题应该如何解决吧。       

面对抛出这样的问题，我们先来了解下生产中有哪些主从架构？线上生产环境一般有一主一从，一主多从，多主一丛（级联复制，MySQL5.7之后才有） ，主主复制。主从架构存在目的就是为了故障切换和读写分离。它的原理如下图：

主云服务器有一个工作线程 io dump thread

从云服务器有两个工作线程，一个是io thread，一个sql thread。

主库把外界接收的SQL请求，记录到自己的binlog日志里面，从库的

io thread去请求主库 的binlog日志，并将得到的binlog日志写到自己的relay log（中继日志） 文件中；主库通过io dump thread，给从库 io thread 传binlog 日志。

大家可以看到在主库上事务的提交是并发模式的，而从库只有一个sql thread 工作，这种不公平的待遇，你说它能不延迟嘛。

剖析其重要的延迟原因在于：

1. 首先就是主库可以并发写入，从库只能通过单sql thread完成任务（MySQL5.7之前）

2. MySQL主从之间的同步，本来就不是时时同步的，是异步的同步，也就是说，主库提交事务之后，从库才再来执行一遍。

3. 在主库上对没有索引大表的列进行delete或者update的操作

4. 从库的硬件配置没有主库的好，经常忽略从库的重要性

5. 网络问题

解决方法如下：

1. 使用MySQL5.7版本，在5.7中引入了基于组提交的并行复制,设置参数slave_parallel_workers>0  和slave_parallel_type＝'LOGICAL_CLOCK'。

MySQL 5.7才可称为真正的并行复制，这其中最为主要的原因就是slave云服务器的回放与主机是一致的。就是说主云服务器上是怎么并行执行的，从库上就怎样进行并行回放。不再有MySQL5.6版本中库的并行复制限制。

2. 可以采用percona公司的percona-xtradb-cluster简称PXC架构，这种架构下可以实现多节点写入，达到时时同步。可参考老张的MySQL高可用架构三部曲之PXC。

链接地址：http://sumongodb.blog.51cto.com/4979448/1956086

3. 业务初期规划的时候，就要选择合适的分库、分表策略，避免单表，或者单库过大。带来额外的复制压力。从而带来主从延迟的问题。

4. 避免一些无用的IO消耗，可以上高转速的磁盘，SSD或者PCIE-SSD设备。

5. 阵列级别要选择RAID10，raid cache策略要使用WB坚决不要WT。

6. IO调度要选择deadline模式。

7. 适当调整buffer pool的大小

8. 避免让数据库进行各种大量运算，要记住数据库只是用来存储数据的，让应用端多分担些压力，或者可以通过缓存来完成。

看完以上关于MySQL主从延迟问题应该如何解决，很多读者朋友肯定多少有一定的了解，如需获取更多的行业知识信息 ，可以持续关注我们的行业资讯栏目的。