MySQL复制过滤器是从库SQL线程回放时按规则决定是否跳过事件的机制，需配置在从库my.cnf中并重启生效，不减少主库压力，匹配依赖当前USE库而非语句显式库名。
什么是 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 测试。
