replicate-wild-do-table 必须写在从库 my.cnf 的 [mysqld] 段并重启 MySQL 进程才生效，仅 reload 或重启线程无效；它按语句文本匹配“库名.表名”，支持跨库操作，不依赖 USE，大小写敏感，% 匹配任意长度字符，不支持正则，不可与 replicate-do-db 混用。
replicate-wild-do-table 必须写在从库配置文件里重启生效
这个参数只对从库起作用，主库配了完全无效。它不是运行时变量，SET GLOBAL 或 CHANGE REPLICATION FILTER 都不能让它持久生效——必须写进从库的 /etc/my.cnf 或 /etc/mysql/my.cnf 的 [mysqld] 段，然后完整重启 MySQL 进程（systemctl restart mysql），仅 reload 配置或只重启 SQL 线程都不行。
常见错误现象：SHOW SLAVE STATUS\G 中 Replicate_Wild_Do_Table 字段为空，或者规则看似写了却没过滤效果，基本就是没重启进程，或者写到了主库配置里。
- 配置位置只能是：从库的
my.cnf→[mysqld]下 - 不支持逗号分隔，每行一个规则，例如：
replicate-wild-do-table = app_db.users、replicate-wild-do-table = app_db.order% - 大小写敏感，取决于底层文件系统（Linux 通常区分，Windows 不区分）
通配符匹配逻辑：只看语句中是否出现“库名.表名”形式
replicate-wild-do-table 不依赖 USE 语句，也不管 SQL 实际操作的是哪个库，它只扫描语句文本里有没有符合 db_name.table_pattern 的显式引用。哪怕你在 USE mysql 后执行 INSERT INTO app_db.users，只要 app_db.users 匹配规则，就会被同步。
这意味着它天然支持跨库操作，比如：INSERT INTO order_db.orders SELECT * FROM app_db.users —— 只要 app_db.users 在规则里，这条语句就会被复制；而 order_db.orders 是否在规则里，不影响该语句是否被应用（除非你另外配了 replicate-wild-ignore-table）。
-
%匹配任意长度字符（含零个），_匹配单个字符，不支持正则 - 规则按顺序逐条匹配，但 MySQL 不保证短路；多个规则同时命中，只要有一条匹配就通过
- 避免写
%.%这种全通配，等价于没过滤，且可能干扰其他规则
别和 replicate-do-db 混用，否则行为不可预测
一旦同时启用 replicate-do-db 和 replicate-wild-do-table，MySQL 会先走库级判断再走表级判断，但两套逻辑的触发条件不同（前者依赖 USE，后者依赖文本匹配），容易导致某些语句被漏掉或重复应用。官方文档明确提示：混搭时规则冲突，行为未定义。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
真实踩坑场景：你配了 replicate-do-db = app_db 和 replicate-wild-do-table = app_db.users，结果 USE mysql; INSERT INTO app_db.users 被跳过——因为 replicate-do-db 先判定当前库是 mysql，直接丢弃整条语句，根本不会走到表匹配阶段。
- 推荐统一用
replicate-wild-do-table，覆盖所有需要的表，包括跨库引用 - 如果必须保留库级控制，至少确保
replicate-do-db和replicate-wild-do-table的库名完全一致，且业务 SQL 全部显式带库名前缀 - 绝对不要和
replicate-ignore-db同时使用，冲突更隐蔽
验证规则是否真正生效，得用跨库语句测
只在目标库下 USE app_db; INSERT INTO users 是不够的，这只能验证 replicate-do-db 类逻辑。要确认 replicate-wild-do-table 生效，必须构造它真正擅长的场景：跨库引用。
例如，你配置了 replicate-wild-do-table = app_db.users，就在主库执行：USE mysql; INSERT INTO app_db.users (name) VALUES ('test')，然后立刻查从库 app_db.users 是否新增记录。再补一句：INSERT INTO app_db.log_2025 (msg) VALUES ('skip')（假设 log_2025 不在规则里），确认它确实没同步。
- 检查
SHOW SLAVE STATUS\G中Replicate_Wild_Do_Table值是否与配置一致 - 观察
Seconds_Behind_Master是否突增——规则误配导致大量语句被跳过时，SQL 线程会快速追平，延迟归零但数据缺失 - 生产环境上线前，务必在测试库用真实业务 SQL 模拟跑一遍，尤其是带 JOIN、子查询、多库 INSERT ... SELECT 的语句
最常被忽略的一点：规则生效后，从库 binlog 里记录的仍是原始语句（除非开了 log_slave_updates 且格式为 ROW），所以如果你的从库还作为其他从库的主库，这些过滤规则不会自动继承——下一级从库看到的是已过滤后的 relay log，而不是原始 binlog。
