replicate-wild-do-table是唯一真正按实际表名白名单过滤的方案，必须主从binlog_format=row、规则仅配从库my.cnf并重启生效；replicate-do-db依赖use上下文，跨库语句直接失效。
直接说结论：replicate-wild-do-table 是唯一能真正按表名白名单过滤主从同步的方案，但必须主从都设为 binlog_format = ROW，且规则只写在从库 my.cnf 里并重启生效。其他所谓“白名单库名”或动态 SET 的做法，基本等于没配。
为什么 replicate-do-db 不是靠谱的白名单
它依赖 USE db_name 上下文，遇到跨库语句就彻底失效。比如主库执行 INSERT INTO log.audit_log SELECT * FROM app.users，哪怕你配了 replicate-do-db = app，这条语句 SQL 线程根本不会解析——直接跳过，从库连日志都不读。
replicate-wild-do-table 则不同，它匹配的是 binlog 事件里实际修改的表名（如 app.users），不看当前默认库，也不管语句怎么写的。
- 支持通配符：
app.user_%匹配app.user_profile、app.user_settings，但不匹配app.users（末尾没下划线） - 大小写敏感：若
lower_case_table_names = 0，APP.USERS和app.users被视为不同表，规则必须严格一致 - 多个规则是“或”关系：满足任一即同步；若同时配了
replicate-wild-ignore-table，它优先级更高，先忽略再判断 do
必须满足的三项硬性条件
缺一不可，否则规则形同虚设：
- 主库和从库的
binlog_format都必须是ROW（STATEMENT或MIXED下官方明确不生效） - 从库
SQL线程必须运行：SHOW SLAVE STATUS\G中Slave_SQL_Running: Yes，且Seconds_Behind_Master不卡住 - 规则必须写在从库的
my.cnf的[mysqld]段里，重启mysqld或执行STOP SLAVE; START SLAVE;才加载
常见错误现象与验证方法
同步看起来正常（Seconds_Behind_Master: 0），但目标表没数据？大概率踩了这些坑：
- 主库执行
CREATE TABLE app.cache_2024没先USE app→ DDL 总是按STATEMENT格式记录 →replicate-wild-do-table对它无效 → 表在从库根本不会被创建 - 规则写成
replicate-wild-do-table = app.user%，但表名实际是APP.USERS→ 文件系统区分大小写，匹配失败 - 误把规则写在主库配置里，或用
SET GLOBAL replicate_wild_do_table = 'app.users'→ 该变量不可动态设置，写错位置等于没配
验证是否真起作用，别只看状态，动手测行为：
- 主库执行：
INSERT INTO app.users (name) VALUES ('test');和INSERT INTO log.audit_log (msg) VALUES ('skip'); - 立刻查从库：
SELECT COUNT(*) FROM app.users;应 +1；SELECT COUNT(*) FROM log.audit_log;应保持不变
最易被忽略的一点：DDL（建表、改表等）在 ROW 模式下仍以 STATEMENT 形式记录，replicate-wild-do-table 对它完全不生效。这意味着白名单只管 DML（增删改查），不管结构变更——如果只同步部分表，建表语句必须手动在从库执行，或用其他方式兜底。
