什么是 MySQL 复制过滤器？它不是“开关”，而是规则集
MySQL 复制过滤器（Replication Filters）是主从复制中控制「哪些数据在从库上执行」的机制，它不阻止主库写入，也不影响 binlog 生成，只在从库 SQL 线程回放时起作用。误以为它能减少主库压力或节省网络带宽，是常见误解。
真正生效的位置在从库：SQL 线程读取 relay log 后，根据
replicate-do-db、
replicate-ignore-table等规则决定是否跳过某条事件。规则匹配基于语句上下文（比如当前
USE的库），而非语句中显式写的库名——这点极易踩坑。 所有过滤参数都必须配置在从库的
my.cnf中（
[mysqld]段），且需重启 mysqld 才生效（除部分动态变量外） 不支持运行时修改大部分过滤参数，例如
replicate-do-db无法用
SET GLOBAL设置 如果同时用了基于行（ROW）和基于语句（STATEMENT）的 binlog 格式，过滤行为可能不一致；推荐统一用 ROW 模式避免歧义
常用过滤参数及典型误配场景
最常被混用的是
replicate-do-db和
replicate-wild-do-table，它们的匹配逻辑完全不同：
replicate-do-db：只对当前默认数据库（即
USE db_name后执行的语句）生效；跨库语句如
INSERT INTO other_db.t1 ...即使目标是白名单库，也会被跳过
replicate-wild-do-table：支持通配符（
%、
_），按表名匹配，不受当前
USE影响；例如
replicate-wild-do-table = myapp\_%可匹配
myapp_user、
myapp_order_2024
replicate-ignore-table不支持通配符，必须写全
db_name.table_name；若想忽略多个表，得逐行写，不能写成
db_name.t%
错误示例：在从库配置了
replicate-do-db = app_log，但主库应用执行的是
INSERT INTO app_log.audit_log ...且未先
USE app_log，这条语句会被直接忽略——因为没有当前库上下文。
如何安全启用过滤而不丢数据？
上线前必须验证规则是否符合预期，不能仅靠文档理解。建议按以下顺序操作：
先在从库停掉 SQL 线程：STOP SLAVE SQL_THREAD;手动执行几条典型语句（含跨库、多表、DDL），观察
SHOW SLAVE STATUS\G中
Exec_Master_Log_Pos是否变化，以及
Relay_Log_Space是否增长 检查
SHOW PROCESSLIST中 SQL 线程状态，确认其是否处于
Waiting for an event from Coordinator（说明没执行）还是
Reading event from the relay log（正在处理） 临时开启
log_warnings = 2并查看错误日志，MySQL 会在跳过事件时记录类似
Filtered replication event for database 'xxx'的提示（5.7+ 默认关闭该日志）
注意：过滤器不会影响 GTID 或事务边界。一个事务里只要有一条语句被匹配到“忽略”，整个事务都会被跳过（在 STATEMENT 模式下）；但在 ROW 模式下，是按行事件逐条判断，更细粒度但也更难预测。
替代方案：为什么现在更推荐用 replicate-rewrite-db
+ 应用层隔离？
当业务需要严格分离数据（比如测试环境只同步部分业务库），硬靠过滤器容易出错。实际运维中，更可控的做法是：
主库按业务拆成多个实例，或用replicate-rewrite-db把指定库重映射到从库不同库名（如
replicate-rewrite-db = app_v1->app_staging），再配合
replicate-do-db控制范围 关键业务表加
COMMENT标记，从库用 pt-table-checksum + 自定义脚本定期校验过滤后数据一致性 避免在生产从库上启用
replicate-ignore-db，它会跳过所有对该库的 DDL（包括
DROP DATABASE），导致后续同名库创建失败
最麻烦的不是配置本身，而是规则与应用行为耦合太深——比如 ORM 自动生成的
USE语句、批量导入工具的连接初始化逻辑，都会让过滤结果变得不可控。上线前务必拿真实 binlog 片段做 replay 测试。
