MySQL复制过滤是指将主库产生的数据变更按照指定规则筛选后，再同步到从库的一种机制。在生产环境中，我们并不总是需要把主库的全部库表都复制到从节点，例如报表从库只需要订单和用户的维度数据，或者分库分表后某些历史库不必再参与同步。通过合理的复制过滤配置，可以显著减少从库磁盘占用、网络传输量和SQL线程回放压力。MySQL的复制过滤可从两个层面着手：一是控制二进制日志本身记录的内容，二是控制从库重放时应用的内容。
基于主库二进制日志的复制过滤配置
主库层面的过滤主要通过 binlog_do_db 和 binlog_ignore_db 两个系统变量实现。当启用 binlog_do_db 后，只有被明确列出的数据库中的修改才会写入二进制日志，其余库的变更将被直接忽略。这种方式的优势在于从源头减少了binlog体积，对网络和应用线程都更友好。但需要注意，这两个参数判断的是当前会话的默认数据库，而不是语句实际操作的库。
例如，当设置了 binlog_do_db=orders 时，如果客户端执行 USE inventory; UPDATE orders.items SET price=1;，由于当前默认库是 inventory，该更新不会被记录。这种跨库操作在复杂业务里非常常见，因此主库过滤很容易造成数据漏同步。配置方式通常是在 my.cnf 的 [mysqld] 段写：
[mysqld] binlog_do_db=orders binlog_ignore_db=test
修改后需重启MySQL或动态设置（但动态设置只对新建连接生效）。主库过滤虽然省资源，但在微服务共享实例、跨库事务等场景下风险较高，一般不作为唯一手段。若确实要用，应配合严格的命名规范和单一默认库连接策略。
基于从库重放规则的复制过滤配置
从库层面的过滤更加灵活，常用变量包括 replicate_do_db、replicate_ignore_db、replicate_do_table、replicate_ignore_table 以及支持通配符的 replicate_wild_do_table 和 replicate_wild_ignore_table。从库在读取中继日志后，会根据这些规则决定是否执行事件。由于是在SQL线程应用阶段判断，它不受默认库选择的影响，能准确按库表名匹配。
推荐使用通配符方式，例如只同步 orders 库下所有表，可写：
[mysqld] replicate_wild_do_table=orders.%
如果还要忽略某张日志表，可追加：
[mysqld] replicate_wild_do_table=orders.% replicate_wild_ignore_table=orders.order_logs
与 replicate_do_table=orders.items 这种固定写法相比，通配符能覆盖后续新建表，减少运维遗漏。配置完成后，需要在从库执行 STOP SLAVE; START SLAVE; 使规则重新加载。从库过滤不减少主库binlog大小，但能降低从库写入量，且规则语义清晰，是大多数团队的首选方案。
过滤规则生效验证与常见故障排查
配置完毕后必须验证复制线程状态和过滤变量是否真正加载。可通过 SHOW SLAVE STATUSG 查看 Replicate_Do_DB、Replicate_Wild_Do_Table 等字段，确认值与配置文件一致。同时观察 Seconds_Behind_Master 与 Retrieved_Gtid_Set、Executed_Gtid_Set 判断同步是否按预期推进。
常见误区之一是修改了 my.cnf 却忘记重启或从库未重启SQL线程，导致旧规则仍生效。其二是混淆了 binlog_do_db 与 replicate_do_db 的作用层面，在双主架构中两边都设主库过滤，结果互相丢失对方数据。其三是在使用GTID模式时，以为过滤后GTID集合会变小，实际上主库仍产生全局GTID，从库只是跳过执行，监控脚本需相应调整。
下面一段SQL可用于在从库检查当前过滤设置：
SHOW VARIABLES LIKE 'replicate%'; SHOW VARIABLES LIKE 'binlog%';
若发现配置未生效，先核对配置文件路径是否被正确加载，使用 SELECT @@config_file; 确认。再检查是否有命令行参数覆盖了配置。最后确保没有在 CHANGE MASTER TO 语句中指定了互斥的过滤选项。通过分层设计与严谨验证，MySQL复制过滤就能稳定支撑各类指定库表同步需求。
MySQL复制过滤binlog_do_db修改时间：2026-08-18 05:26:13