名词解释：
文件：
binlog：主库存二进制日志的
relay-log：从库接收主库的二进制日志临时存放处。
master.info：从库中存放主库的信息处
relay-log.info：存上次接收到的relay-log位置点的信息处
线程：
binlog_dump_thread:主库用于进行二进制投递的线程
io和sql线程：从库复制的线程
主从延时原因分析：
一检查从库延时主库的时间(单位秒)，执行语句mysql> show slave status \G
Seconds_Behind_Master:0
二是否执行了双一标准：
双1标准：
在主库中执行：mysql> select @@innodb_flush_log_at_trx_commit;查看值是否是1：
innodb_flush_log_at_trx_commit = 1，这也是Innodb的默认设置。我们每次事务的结束都会触发Log Thread 将log buffer中的数据写入文件并通知文件系统同步文件。这个设置是最安全的设置，能够保证不论是MySQL Crash 还是OS Crash或者是主机断电都不会丢失任何已经提交的数据。
在主库中执行Mysql> select @@sync_binlog，查看值是否是1：
sync_binlog=1，表示每次事务提交，MySQL都会立即刷新binlog，是最安全但是
能损耗最大的设置。这样的话，在数据库所在的主机操作系统损坏或者突然掉电的情况下，系统才有可能不丢失1个事务的数据。
三主库的并发业务太高
如果并发业务太高影响力主从延时，可以考虑升级硬件或者考虑分布式架构
四从库太多：
可以在主库和从库之间架设一台中间库，同时中间库只负责rely_log和bin_log，而不进行数据写入，进行级联主从的方法进行处理（不推荐）
五：对于传统的Classic Replication主从复制搭建，主库并发运行事物，但Dump_T在传输日志的时候是以时间为单元串行的方式传输，从而产生主从延时：
处理办法：
使用group commit方式搭建主从，从mysql5.6版本以后，引入了GTID编号，在同一时间提交的事务GTID号一致，因此主推开启GTID复制，并且要双一保证，这样就可以保证Dump_T传输的方式以GTID号为组进行并行传输至从库。
从库方面原因：
传统的classic replication主从复制的SQL线程只有一个，也就是说我们从主库一下子拿来100个事物存放在relay_log里，而从库里的SQL线程对事物进行一个一个的串行回放，
处理办法：
mysql5.7版本以后加入了MTS，真正实现了事物级别的并发
