replicate_do_db 依赖 USE 语句且存在诸多缺陷，真正可靠的替代方案是 replicate_wild_do_table。该参数不依赖 USE，直接解析 binlog 中库表名，支持通配符匹配、跨库语句识别，修改后仅需重启 IO 线程即可生效。
replicate_do_db 依赖 USE，但应用根本不按它写 SQL
这个参数不是“只要操作了指定库就复制”，而是检查当前会话是否执行过 USE db_name。一旦应用用显式库名（比如 INSERT INTO log_db.audit_log）或 ORM 自动生成跨库语句，replicate_do_db 就完全失效。
常见现象包括：
- 从库
SHOW SLAVE STATUS\G显示Replicate_Do_DB: app_db，但monitoring库的变更仍在同步 -
mysqldump --databases 导出多库脚本后恢复，部分库被跳过——因为 dump 文件里每条语句前没加
USE -
CREATE TABLE app_db.t1在USE tmp_db下执行 → 整个语句被忽略，导致从库表缺失
GTID 模式下无法动态修改，必须重启从库
开启 gtid_mode=ON 后，MySQL 要求所有复制过滤参数在从库首次启动前就写进配置文件。运行中执行 SET GLOBAL replicate_do_db = 'app_db' 会直接报错：Variable 'replicate_do_db' is a read only variable。
这意味着：
- 临时调整过滤规则不可行，必须停服重启 IO 线程甚至整个实例
- 自动化运维脚本容易因权限或状态判断失败而中断
- 和现代 MySQL 的在线变更习惯严重冲突
与 replicate_wild_do_table 混用时行为不可预测
如果配置里同时存在 replicate-do-db = app_db 和 replicate-wild-do-table = app_db.users，MySQL 会按“更精确规则优先”处理；但一旦再加一行 replicate-ignore-db = tmp_db，逻辑就彻底混乱——白名单和黑名单无明确执行顺序，MySQL 不保证哪条先匹配。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
更麻烦的是：
-
replicate-ignore-db在 MySQL 8.0.26+ 已被标记为deprecated - 两套规则共存会让
SHOW SLAVE STATUS输出难以解读，排查延迟或跳过问题时极易误判 - 升级到 MySQL 8.4 或更高版本时，这些参数可能被直接移除
真正可靠的替代方案只有 replicate_wild_do_table
通配符过滤不依赖 USE，直接解析 binlog 事件里的库名和表名。例如：
replicate-wild-do-table = app_% .% replicate-wild-ignore-table = mysql.% replicate-wild-ignore-table = performance_schema.%
这样做的好处是：
- 跨库语句（如
INSERT INTO app_log.audit SELECT * FROM app_core.users）也能精准匹配目标表 - 支持
%和_，可批量过滤日志表（app_log.tmp_%）、缓存表（cache_*）等 - 修改后只需执行
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;即可生效，无需重启实例
复杂点在于：通配符规则是逐条匹配的，多个 replicate-wild-do-table 之间没有“或”逻辑，必须确保覆盖所有需要同步的库表模式；漏写一条，对应数据就永远不同步。
