replicate_do_db和replicate_ignore_db在STATEMENT复制下仅检查USE库名，不检查SQL实际操作的库，存在严重过滤失效风险；应改用replicate_wild_do_table按真实表名通配匹配，且需配置在从库my.cnf的[mysqld]段并重启生效。
replicate_do_db 和 replicate_ignore_db 的行为陷阱
这两个配置项看似直观，实际在语句级复制（STATEMENT）下有严重歧义：它们只检查 USE 当前库，不检查 SQL 语句真正操作的库。比如执行 USE test; INSERT INTO production.users VALUES (...);，即使 replicate_ignore_db = test，数据仍会写入从库的 production 库——因为过滤只看 USE，不看表名前缀。
所以：不要依赖 replicate_do_db 或 replicate_ignore_db 做精确库级过滤，尤其当业务中存在跨库操作或未显式 USE 的场景。
真正可靠的过滤方式：replicate_wild_do_table
该参数支持通配符，按实际表名匹配，不受 USE 影响，是目前最稳定的选择。它在 IO 线程写 relay log 阶段就过滤，不浪费网络和磁盘资源。
- 只同步
app_%开头的库下的所有表：replicate_wild_do_table = app\_%.% - 只同步
orders库里的user_*表：replicate_wild_do_table = orders.user\_% - 可配置多行，每行一个规则（MySQL 5.7+ 支持）
- 注意反斜杠要转义：库名含下划线时必须写成
app\_db，否则_被当作通配符
配置生效前提与重启要求
这些 replicate_* 参数属于从库启动参数，不能在线 SET，必须写入 my.cnf 并重启 mysqld。动态修改会被忽略，且错误日志里不会报错，容易误以为生效了。
- 配置位置：必须放在从库的
[mysqld]段下，主库配置无效 - 检查是否加载成功：
SHOW VARIABLES LIKE 'replicate%';—— 确认输出值与配置一致 - 若已运行复制，重启后需手动
START SLAVE;，状态会从Seconds_Behind_Master: NULL重置为正常延迟值
row 格式 + 过滤规则的兼容性注意事项
使用 binlog_format = ROW 时，replicate_wild_do_table 依然有效，但要注意：ROW 日志中表名是完整三元组（db_name.table_name），所以规则中的库名部分必须精确匹配，大小写敏感（取决于 lower_case_table_names 设置）。
- 如果主库
lower_case_table_names = 1，从库也必须设为 1，否则replicate_wild_do_table = MyDB.%可能不匹配实际写入的mydb.% -
replicate_rewrite_db在 ROW 模式下完全失效，不要混用 - 过滤发生在 SQL 线程解析 relay log 之前，因此被过滤的事件不会触发任何触发器或外键检查
配置过滤规则不是加一行参数就完事的事，关键在匹配逻辑是否覆盖真实 SQL 行为、格式是否匹配、重启是否到位——漏掉任意一点，都可能让不该同步的数据悄悄流过去。
