主库的binlog_do_db和binlog_ignore_db仅在USE匹配且STATEMENT格式下生效，跨库操作失效，MySQL 8.0+已弃用；从库的replicate_do_db等同样依赖USE，行为反直觉；推荐使用replicate_wild_do_table/ignore_table通配符过滤或复制通道实现可靠、灵活的库表级复制控制。
主库用 binlog_do_db 和 binlog_ignore_db 过滤时，从库收不到预期的 binlog
这两个参数只在当前服务器的 USE 数据库匹配时才生效，且基于语句复制（STATEMENT）逻辑，对 INSERT INTO db1.table1 SELECT * FROM db2.table2 这类跨库操作完全失效。更关键的是：它们作用于主库，但实际复制行为由从库的 SQL 线程解析事件后执行，而主库写入 binlog 时已丢弃被忽略的库操作——导致从库根本收不到任何相关事件，连过滤机会都没有。
实操建议：
- 除非你 100% 使用
STATEMENT格式 + 每条语句前都显式USE db_name，否则别碰这两个参数 - MySQL 8.0+ 已将它们标记为 deprecated，未来版本会移除
- 真正可控、可预测的过滤必须放在从库侧
从库用 replicate_do_db 和 replicate_ignore_db 的坑
它们看似直观，但行为反直觉：不是“只复制/忽略某个库”，而是“仅当当前 USE 库匹配时才执行该事件”。这意味着：
-
INSERT INTO db1.t1 VALUES (1)在USE db2下执行 → 即使目标表是db1.t1，也会被跳过 -
CREATE TABLE db1.t1 (id INT)在USE db1下执行 → 被复制，但后续往db1.t1插数据时若没USE db1，仍可能被跳过 - 对
mysqldump --databases导出的多库脚本极不友好，容易漏复制
所以这些参数只适合极简场景（如单库应用 + 严格控制连接默认库），生产环境应避免。
推荐方案：用 replicate_wild_do_table 和 replicate_wild_ignore_table
通配符过滤才是可靠选择，它直接匹配事件中的库名和表名，与当前 USE 无关。例如：
replicate_wild_do_table = app_% .% replicate_wild_ignore_table = mysql.%
这表示只复制库名以 app_ 开头的所有表，同时明确排除 mysql 系统库所有表。注意语法细节：
- 格式固定为
db_pattern.table_pattern，中间是英文点号，不是下划线或斜杠 -
%匹配任意字符（包括空），_匹配单个字符；app\_prod.%中的反斜杠用于转义下划线字面量 - 多个规则用逗号分隔，但 MySQL 不保证顺序执行，冲突时以“最具体匹配”为准（如
app1.%和app%.%同时存在，app1.t会命中前者） - 修改后需重启从库或执行
STOP SLAVE; START SLAVE;生效，不支持动态 SET
更灵活的替代：使用复制通道（Replication Channels）配合 CHANGE REPLICATION FILTER
MySQL 5.7+ 支持多通道复制，每个通道可独立配置过滤规则。相比全局变量，它允许按用途隔离策略，比如：
CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('app_core.%') FOR CHANNEL 'core_channel';
CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('app_log.%') FOR CHANNEL 'log_channel';这样两个通道可分别拉取不同业务子集，互不影响。优势在于：
- 规则可在线修改（无需重启），执行
STOP SLAVE FOR CHANNEL 'xxx'; START SLAVE FOR CHANNEL 'xxx';即可重载 - 配合
START SLAVE UNTIL可做灰度同步、临时跳过某段 binlog - 监控时可通过
performance_schema.replication_applier_status_by_coordinator查看各通道状态
唯一复杂点是管理成本上升——你需要显式创建通道、指定 MASTER_AUTO_POSITION=1 或手动定位 GTID，且备份恢复时要确保通道配置也被保留。
