replicate-wild-do-table是唯一靠谱的白名单方案，因它按实际表名匹配、不依赖use语句，支持跨库写入、无默认库及ddl识别；必须主从binlog_format=row，规则配于从库my.cnf并重启生效。
必须用 replicate-wild-do-table，且主从都设为 binlog_format = ROW，否则规则完全不生效。
为什么 replicate-wild-do-table 是唯一靠谱的白名单方案
它按实际修改的表名匹配，不依赖 USE 语句上下文，跨库写入、无默认库、DDL 操作都能稳定识别。而 replicate-do-db 在 INSERT INTO other_db.t1 SELECT * FROM main_db.t2 这类语句中直接失效——SQL 线程连解析都不解析，整条跳过。
-
replicate-wild-do-table = app.users匹配app.users，但不匹配app.users_bak（末尾没下划线） -
replicate-wild-do-table = app.user%匹配app.user_profile、app.user_settings，也匹配app.users（%可匹配零个字符） - 多个规则是“或”关系，满足任一即执行；若同时配了
replicate-wild-ignore-table，它优先级更高，先忽略再判断 do
配置前必须确认的三项硬性条件
缺一不可，否则即使参数写对，数据也不同步：
- 主库和从库的
binlog_format都必须是ROW（STATEMENT或MIXED下replicate-wild-do-table官方明确不生效） - 从库 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→ 文件系统区分大小写，lower_case_table_names=0时匹配失败 - 误把规则写在主库配置里，或写成
SET GLOBAL replicate_wild_do_table = 'app.users'→ 该变量不可动态设置，写错位置等于没配
验证规则是否真正起作用的实操方法
别只看 SHOW SLAVE STATUS，要动手测行为：
- 在主库执行：
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;应保持不变 - 关键动作：执行
STOP SLAVE SQL_THREAD;后再插入，观察Relay_Log_Space是否增长 —— 增长说明 IO 线程收到了日志，但 SQL 线程被规则拦住了
表名通配逻辑简单，但 DDL 和大小写是高频翻车点，上线前务必用真实建表+插入组合跑一遍。
