replicate-do-db不建议在生产环境直接使用，因其仅按USE指定的当前库匹配，不检查SQL实际操作的表所属库，易导致漏同步或误跳过；必须重启mysqld生效，不支持动态修改，且优先级低于replicate-ignore-db。
replicate-do-db 在绝大多数生产场景下不建议直接使用——它不是“只同步这个库”的开关，而是依赖 SQL 执行时的 USE 上下文，极易漏同步或误跳过。
replicate-do-db 匹配逻辑完全依赖 USE 语句
它只看当前连接的默认数据库（即执行了 USE db_name 或连接时指定了 --database=db_name），不看 SQL 里实际操作的是哪个库的表。例如：
- 执行
USE test; INSERT INTO prod.users VALUES (...);→ 当前库是test，哪怕目标表在prod，只要没配replicate-do-db = test，整条语句就被跳过 - 执行
USE prod; UPDATE log_table SET ...;→ 即使你只想同步prod的业务表，但这条日志表更新仍会被复制，因为当前库匹配了 - 没有
USE、也不带库名前缀的语句（如UPDATE users SET ...）→ MySQL 视为「无当前库」，replicate-do-db完全不生效，语句被丢弃
配置多个数据库必须重复写多行，不能用逗号
想同步 sales 和 users 两个库？以下写法是错的：
replicate-do-db = sales,users
正确写法是：
replicate-do-db = sales<br>replicate-do-db = users
MySQL 会把每一行当作独立规则加载；逗号分隔会被当成一个数据库名（比如叫 sales,users 的库），显然不存在。
replicate-ignore-db 优先级永远高于 replicate-do-db
如果同时配置了：
replicate-do-db = sales<br>replicate-ignore-db = sales
结果是：整个 sales 库都被忽略——replicate-ignore-db 生效，replicate-do-db 被覆盖。这种冲突常见于临时加 ignore 规则但忘了清理旧 do 规则，导致同步意外中断。
更危险的是混合配置不同库：
replicate-do-db = salesreplicate-ignore-db = logs- 某条语句是
USE sales; INSERT INTO logs.audit_log ... - → 当前库是
sales（匹配 do），但操作表属于logs（匹配 ignore）→ 实际行为取决于 MySQL 版本和 binlog_format，5.7+ ROW 模式下可能跳过，STATEMENT 模式下大概率仍执行
真正生效前必须重启复制线程，SET GLOBAL 无效
replicate-do-db 是只读启动参数，运行时无法动态生效：
-
SET GLOBAL replicate_do_db = 'sales';→ 直接报错：Unknown system variable 'replicate_do_db' - 改完
my.cnf后只执行STOP SLAVE; START SLAVE;→ 规则不会重载，SQL 线程继续按旧规则跑 - 正确做法：修改配置文件 → 重启 mysqld 进程（
systemctl restart mysqld），或至少确保 SQL 线程重建（部分版本需RESET SLAVE ALL;后重新CHANGE MASTER TO）
验证是否加载成功，MySQL 8.0.23+ 可查：SELECT * FROM performance_schema.replication_applier_filters;；旧版本只能靠 SHOW VARIABLES LIKE 'replicate%'; 看配置项，但不反映运行时实际生效状态。
跨库操作、无 USE 语句、大小写敏感、忽略优先级、无法热加载——这些不是边缘情况，而是 replicate-do-db 的默认行为。真要只同步特定库，不如直接用 replicate-wild-do-table 锁死表名模式，或者干脆在应用层控制写入库上下文。否则，数据缺失往往悄无声息，直到某次故障排查才暴露出来。
