mysql主从复制过滤核心是“主库源头控制+从库精准应用”：主库用binlog-do-db/binlog-ignore-db减少日志生成，从库用replicate-do-db/replicate-wild-do-table等参数选择性执行，推荐双保险策略并避免do/ignore混用。
只同步关键业务数据，核心是控制复制范围——不是靠应用层过滤，而是通过 MySQL 自身的 binlog 和复制过滤机制，在日志生成或应用阶段做精准裁剪。重点在于“在哪过滤”和“怎么配”，而不是后期清洗。
主库侧：控制日志源头
在主库写入前就限制哪些库/表被记录进 binlog，从源头减少冗余日志，降低网络和从库压力。
-
binlog-do-db：仅记录指定数据库的操作（如
binlog-do-db=test1,test2），未列出的库不记 binlog，从库自然收不到； -
binlog-ignore-db：明确排除系统库或非业务库（如
binlog-ignore-db=mysql,information_schema,performance_schema），避免权限、统计等无关变更污染复制流； - 注意：
binlog-do-db和binlog-ignore-db是语句级判断，对跨库操作（如INSERT INTO db1.t1 SELECT * FROM db2.t2）可能失效，此时建议改用 ROW 格式 + 从库过滤更稳妥。
从库侧：按需应用日志
即使主库发了全量 binlog，从库也能选择性执行——这是更灵活、更常用的方式，尤其适合多租户或分库分表场景。
-
replicate-do-db：只应用指定数据库的 relay log（如
replicate-do-db=finance,order）； -
replicate-ignore-db：跳过某些库（如
replicate-ignore-db=log,tmp），但要注意：这些库的日志仍会写入 relay log，只是 SQL 线程不执行； -
replicate-wild-do-table：支持通配符，适合按命名规则筛选（如
replicate-wild-do-table=finance.usr_%只同步 finance 库下以usr_开头的表）； -
replicate-wild-ignore-table：反向屏蔽（如
replicate-wild-ignore-table=finance.%_history忽略所有带_history后缀的历史表）。
组合使用与避坑要点
实际生产中，推荐“主库粗筛 + 从库精控”双保险，兼顾效率与可控性。
- 主库设
binlog-ignore-db排除系统库和测试库，避免无谓传输； - 从库用
replicate-wild-do-table明确限定关键表（如finance.user_info、order.order_main、pay.transaction_log），比库级过滤更精确； - 避免混用
do和ignore规则——MySQL 按顺序匹配，一旦命中do就不再检查ignore，容易误判； - 所有配置修改后必须重启 MySQL 或执行
STOP SLAVE; START SLAVE;生效，且需确认SHOW SLAVE STATUS\G中无Seconds_Behind_Master异常增长。
验证与监控建议
过滤不是一劳永逸，要持续验证是否真正生效。
- 在从库执行
SELECT DATABASE(), TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA IN ('finance','order');确认只有目标库表存在； - 在主库更新一个被忽略的表（如
log.audit_log），再查从库对应表是否无变化； - 定期检查
SHOW SLAVE STATUS\G中的Replicate_Do_DB、Replicate_Wild_Do_Table字段，确保配置未被覆盖； - 结合慢日志和复制延迟指标，确认过滤后 SQL 线程负载明显下降。
