关于MySQL主从复制的过滤，例如通过binlog-ignore-db、replicate-do-db、replicate-wild-do-table等。如果不好好研究过这些过滤选项就用的话，是有可能造成主从数据不一致问题的。本文将参考MySQL-5.5官方文档并结合实验，和各位一起探讨下这里的各个设置。

? ? 以下内容参考5.5官方文档

binlog_format（STATEMENT，ROW，MIXED，5.5默认为STATEMENT）的设置会导致一些复制执行上的差异。

当使用MIXED格式时，binlog绝大多数情况也是以STATEMENT格式记录，只有在下列情况下才会切换到ROW格式：

1、?当时用UUID()函数时

2、?当一个或多个拥有AUTO_INCREMENT列的表被更新同时有‘trigger’或者‘stored?function’被调用时

? #?MIXED对于‘trigger’和‘stored?function’总是使用statement-based

3、?执行INSERT?DELAYED时

4、?当视图里的某一部分需要row-based复制（例如UUID()）时，创建该视图的语句被改为row-based

5、?使用用户自定义函数（UDF）时

6、?当某语句被判定为row-based，并且执行它的session需要用到临时表，则session下的所有子语句都将以ROW格式记录

7、?当使用USER(),CURRENT_USER()或者?CURRENT_USER

8、?当语句引用了一个或多个system?variables。

9、?当使用LOAD_FILE()

所有DDL语句都是基于statements，不论binlog_format如何设置

复制双方binlog_format需一致，否则复制无法进行

Binlog格式影响到以下‘复制过滤’配置的行为

?

?

总结：Statement-based跟当前use的库有关，Row-based更直接，只关心指定的库‘做或不做’。

还有以下两种参数可‘过滤复制’
以下两种选项只对表的更改有影响，库的复制不受这些参数影响（但是类似ljk.%这种，也会对库起作用）

?

?

?

根据以上，综合建议：对复制的过滤，采用replicate-wild-do-table/?replicate-wild-ignore-table，比较严格和明确

下面是实验过程（MySQL-5.5.39）
一、 主库添加“binlog-ignore-db = mysql”，从库不加过滤

?

?

二、从库添加“replicate-ignore-db = mysql”，主库不加过滤

?

?

三、从库添加“replicate-ignore-table = mysql.%”，主库不加过滤

?

?

四、 从库添加“replicate-wild-ignore-table = mysql.%”，主库不加过滤

?

?

综上参考官方文档以及实验，可得出结论：

对于每一个添加的‘复制过滤’配置，应从两方面考虑：

? ? 1. 不用use语句引用库，或者use xxx引用其他库之后再执行sql（又分两部分：对‘过滤的库/表’ 或 ‘对其他库/表’）会怎样

? ? 2. use xxx引用‘过滤的库/表’，再执行sql（也分两部分：对‘过滤的库/表’ 或 ‘对其他库/表’）会怎样

除replicate-wild-do-table=/replicate-wild-ignore-table=外，其他过滤规则会受到“binlog_format”以及“当前所在库”的影响（即所谓的跨库问题）

实验也验证了上文提到的“对复制的过滤，采用replicate-wild-do-table/?replicate-wild-ignore-table，比较严格和明确”