replicate-wild-do-table能实现表级精确同步，是MySQL主从复制中最常用可靠的方式；它在从库SQL线程解析relay log时匹配通配符（%、\_），不影响主库binlog完整性，需配合ROW格式binlog并重启SQL线程生效。
replicate_wild_do_table 能不能只同步特定表
能，而且这是 MySQL 主从复制中实现「表级精确同步」最常用、最可靠的方式。它不是在主库过滤日志，而是在从库 SQL 线程解析 relay log 时做匹配，决定是否执行该事件——所以不影响主库 binlog 完整性，也避免了跨库语句被误判的问题。
常见错误现象：replicate-do-table=db1.t1 对分表 t1_202501、t1_202502 无效；或者配置了 replicate-do-db=db1 后，INSERT INTO db2.t2 SELECT * FROM db1.t1 被跳过，导致数据不一致。
-
replicate-wild-do-table支持通配符：%匹配任意字符序列，_匹配单个字符 - 推荐写法：
replicate-wild-do-table=db1.table_0%（同步table_01、table_02等），或replicate-wild-do-table=db1.log\_%（注意反斜杠转义下划线） - 多个表需多行配置，不能用逗号分隔
- 该参数仅在从库生效，主库无需任何改动
为什么不用 replicate-do-table 而选 replicate-wild-do-table
因为 replicate-do-table 是精确全名匹配，无法覆盖动态建表、分表、影子表等真实场景；而 replicate-wild-do-table 天然适配这类命名模式，且优先级高于 replicate-ignore-table，规则更可控。
使用场景：业务库中只同步 orders、users 表及其历史分表（如 orders_2025Q1），但忽略所有 log_* 和 tmp_* 表。
replicate-wild-do-table=db1.orders%replicate-wild-do-table=db1.users%replicate-wild-ignore-table=db1.log%replicate-wild-ignore-table=db1.tmp%
注意：如果同时配置了 replicate-do-db，会先按库过滤；若库没命中，后续表级规则直接不生效——所以纯表级控制时，建议清空所有 replicate-do-db 和 replicate-ignore-db。
配置后必须重启 SQL 线程，否则不生效
MySQL 不支持热加载复制过滤规则。改完 my.cnf 后，必须停掉 SQL 线程、重载配置、再启动，否则 SHOW SLAVE STATUS\G 里看到的仍是旧规则。
- 停 SQL 线程：
STOP SLAVE SQL_THREAD; - 重载配置（需重启 mysqld 或执行
SET PERSIST，MySQL 8.0.22+ 支持动态设置，但仅限部分变量） - 启动 SQL 线程：
START SLAVE SQL_THREAD; - 检查是否生效：
SHOW SLAVE STATUS\G中查看Replicate_Wild_Do_Table字段值
容易踩的坑：以为改完配置文件就自动生效，结果同步还在全量跑；或者只执行 START SLAVE，没指定 SQL_THREAD，导致 IO 线程和 SQL 线程一起重启，引发不必要的延迟波动。
ROW 格式 binlog 是表级过滤的安全前提
如果主库用的是 STATEMENT 格式，某些跨库更新、函数调用、非确定性语句可能在从库重放失败，或绕过表名判断逻辑（比如 INSERT INTO db2.t2 SELECT * FROM db1.t1 可能被当成对 db2.t2 的操作，而你只配了 db1.t1 的白名单）。
- 主库务必设置：
binlog_format = ROW - 验证方式：
SELECT @@binlog_format;返回ROW - ROW 模式下，每个变更都带明确的库名+表名元数据，
replicate-wild-do-table才能准确匹配
兼容性影响：MySQL 5.7+ 全支持，但低版本（如 5.6）不支持 SET PERSIST 动态设参，必须重启；另外，多源复制（multi-source）下每个通道可独立配置过滤，但 replicate-wild-do-table 是全局作用于所有通道的，这点容易混淆。
真正麻烦的从来不是加几行配置，而是规则叠加顺序、通配符转义、以及 ROW 日志和 DDL 的配合——漏掉任何一个，都可能让从库悄悄丢数据，还查不出错在哪。
