MySQL的主从复制，实际上就是Master记录自己的执行日志binlog，然后发送给Slave，Slave解析日志并执行，来实现数据复制

对于复制效率，binlog的大小是非常重要的因素，因为它涉及了I/O和网络传输

主从复制涉及到了两端：master/slave，看下这两端可以如何优化

（1）master 端

master端有2个参数可以控制

Binlog_Do_DB : 设定哪些数据库需要记录Binlog

Binlog_Ignore_DB : 设定哪些数据库不要记录Binlog


这两项很重要，指定必要数据库，忽略不需要复制的数据库，可以减少binlog的大小，提高了I/O效率，加快网络传输

但这两项也同样比较危险，需要谨慎使用，因为可能会有主从数据不一致和复制出错的风险

因为MySQL判断是否须要复制某个Event，不是根据产生该Event的语句所在的数据库，而是根据执行时所在的默认数据库，也就是登录时指定的数据库，或运行“USE DATABASE”中所指定的数据库

如果执行语句中明确指定了数据库名称，而这个数据库是被指定不记录Binlog的，那么这个语句在slave中执行时就会出错

例如

garbage 库是被指定不记录日志的

product 库是指定要记录日志的

执行下面的语句

use product;
delete from garbage.junk;

delete语句会被发送给slave，但slave中没有garbage库，所以执行时报错，复制失败


（2）slave 端

slave端有6个参数可以控制

Replicate_Do_DB : 设定须要复制的数据库，多个DB用逗号分隔

Replicate_Ignore_DB : 设定可以忽略的数据库

Replicate_Do_Table : 设定须要复制的Table

Replicate_Ignore_Table : 设定可以忽略的Table

Replicate_Wild_Do_Table : 功能同Replicate_Do_Table，但可以带通配符来进行设置

Replicate_Wild_Ignore_Table : 功能同Replicate_Ig-nore_Table，可带通配符设置


slave端的配置优化效果要明显小于master端的，因为master端日志都写完了，日志也传过来了

但这几个参数可以帮助我们减少日志的应用量，因为设置了过滤，实际写入的sql数量变少了，slave端的复制也就加快了