replicate-wild-do-table 是从库表级复制过滤规则，仅匹配 dml（insert/update/delete/replace）和部分 ddl（create/drop table），不生效于 truncate、alter、存储过程等；配置需写入 my.cnf [mysqld] 段并重启，多规则需分行书写，忽略规则优先级更高。
replicate-wild-do-table 是什么，能过滤哪些 SQL
它不是用来“执行特定 SQL”，而是让从库只同步匹配通配符的表——INSERT、UPDATE、DELETE、REPLACE 这类 DML，以及 CREATE TABLE、DROP TABLE 等 DDL（前提是没用 --skip-slave-start 或手动 START SLAVE 启动）。
它**不生效于**：TRUNCATE TABLE（被当作 DDL 但实际不触发该规则）、ALTER TABLE（部分版本不匹配）、存储过程/函数定义、事件、用户权限变更。更关键的是：它对跨库语句（比如 INSERT INTO db1.t1 SELECT * FROM db2.t2）只检查目标表 db1.t1，源表 db2.t2 完全不校验。
怎么写配置才真正生效
必须在从库的 my.cnf 的 [mysqld] 段里配置，且重启 mysqld（或用 SET PERSIST + RESTART，但注意 8.0.23+ 才支持持久化变量热生效）；仅靠 CHANGE REPLICATION SOURCE TO 不起作用。
-
replicate-wild-do-table = db1.%→ 匹配db1下所有表，但db1_sub不算 -
replicate-wild-do-table = %.t_log_%→ 匹配所有库中以t_log_开头的表，如app.t_log_2024 - 多个规则要写多行，不能逗号分隔：
replicate-wild-do-table = app.%replicate-wild-do-table = log.t_access - 如果同时用了
replicate-wild-ignore-table，忽略规则优先级更高（哪怕 do 先写）
常见错误现象和排查方向
明明配了 replicate-wild-do-table = test.%，但从库还是同步了 prod.user？大概率是主库 binlog_format = STATEMENT，而语句里用了函数（如 NOW()、UUID()），导致从库回放时自动切换成 ROW 格式，此时 wild 规则直接失效——因为 MySQL 在 ROW 模式下只根据 table_map_event 的库名/表名匹配，但某些旧版本（5.6/5.7）对库名解析有 bug，比如把 test 解成空字符串。
其他典型问题：
- 从库启动后
SHOW SLAVE STATUS\G中Replicate_Wild_Do_Table显示为空 → 配置没加载，检查 my.cnf 路径、段落名、拼写（别写成replicate-wild-do-tables） - 同步延迟突然飙升，且
Seconds_Behind_Master持续增长 → 可能匹配了太多表，IO 线程仍拉全量 binlog，SQL 线程却要逐条判断是否跳过，加重负担 - 执行
CREATE DATABASE test2后，再建test2.t，发现没同步 →replicate-wild-do-table不控制库级操作，CREATE DATABASE本身不会被过滤，但后续对该库表的操作才会按规则判断
替代方案比它更可控的场景
如果目标是“只执行某几条 SQL”，比如只同步某个定时任务的更新，replicate-wild-do-table 就不是正解。这时该考虑：
- 主库侧用
binlog_ignore_db/binlog_do_db（但同样有跨库语句陷阱） - 用
replication filters的新语法（MySQL 8.0.23+）：CHANGE REPLICATION SOURCE TO SOURCE_REPLICATE_DO_TABLE = ('app.%', 'log.t_access');，支持运行时修改，且与 ROW 模式兼容更好 - 业务层拆库：把需要同步的表单独放在一个逻辑库，再配合
replicate-do-db（注意它只对USE db显式指定的语句有效） - 终极办法：停掉 SQL 线程，用
mysqlbinlog解析 binlog，人工筛选出目标语句，再在从库执行 —— 复杂但 100% 精确
真正难的从来不是加一行配置，而是确认那条 SQL 到底走的是 STATEMENT 还是 ROW、binlog event 里记录的库名是不是你预期的、以及从库解析时有没有隐式转换。这些细节不查 SHOW BINLOG EVENTS 和 mysqlbinlog -v 输出，光看文档很容易漏掉。
