MySql主从复制

语句优化
不能用select *
挑选适当的索引优化
主从复制的流程
1)、在master机器上的操作：
　 当master上的数据发生变化时，该事件变化会按照顺序写入bin-log中。当slave链接到master的时候，master机器会为slave开启binlog dump线程。当master的binlog发生变化的时候，bin-log dump线程会通知slave，并将相应的binlog内容发送给slave。
2)、在slave机器上操作：
　 当主从同步开启的时候，slave上会创建两个线程：I\O线程。该线程连接到master机器，master机器上的binlog dump 线程会将binlog的内容发送给该I\O线程。该I/O线程接收到binlog内容后，再将内容写入到本地的relay log；sql线程。该线程读取到I/O线程写入的ralay log。并且根据relay log。并且根据relay log 的内容对slave数据库做相应的操作。
　
主从复制延迟产生的原因:
1,备库机器性能比主库所在的机器性能差,如果机器的资源不足的话就会影响备库同步效率
2.备库充当了读库,一般写的压力在主库,读的压力在备库,如果备库的查询压力过大,查询消耗大量CPU资源,就会影响到同步的速度
3.大事物的执行,如果事务的执行持续了10分钟,那么binlog的写入必须要等待事务完成之后,才会传入备库,那么开始执行时候就会延迟10分钟
4 .主库的写操作是顺序写binlog,从库单线程去主库顺序读binlog,读取到后之后在本地执行(relaylog),mysql的主从复制是单线程的,但由于主库的顺序写,读库也是顺序读效率会很高,当数据拉取回来之后变成了随机的操作,而不是顺序的,所以成本会提高
5.从库在同步数据时候,可能跟其他查询的线程发生锁抢占的情况,此时也会发生延迟
6.当主库的TPS并发非常高的时候,产生的DDL数量超过线程所承受的范围,那么也可能带来延迟
7.在进行binlog日志传输的时候,如果网络带宽不是很好,也会发生延迟
如何解决主从复制问延迟问题:
5.6版本之后开始引入并行复制
所谓并行复制就是在中间添加一个分发的环节,原来的sql_thread变成了coordinator组件,当日志来了coordinator负责读取日志以及分发事务,真正日志的执行过程在worker上并行执行
MTS:MULTI-THREAD SLAVE 并行复制
5.6只支持库的并行复制效率很低,5.7开始支持表和行的
并行复制分发规则
1.更新同一行的多个事务,必须放到同一个worker中执行
2.同一个事务不能被拆开,必须放到同一个worker中执行