是，CHANGE REPLICATION FILTER 在 MySQL 8.0.23+ 中立即生效，但仅影响后续新建复制事件，已拉取未执行的 relay log 不受影响；5.7 不支持该语句，需停库修改配置并重启。
CHANGE REPLICATION FILTER 会立即生效吗？
会，但仅对后续新建的复制事件生效，已拉取但未执行的 relay log 不受影响。MySQL 8.0.23+ 支持该语句，低于此版本只能停库改 my.cnf 并重启 IO 线程。
-
CHANGE REPLICATION FILTER修改的是 SQL 线程的过滤逻辑，不触碰 IO 线程拉取行为 - 修改后需确认
SHOW REPLICA STATUS\G中Replica_SQL_Running_State无异常卡顿 - 若正在执行大事务，过滤规则变更不会中断它——事务内所有语句仍按旧规则判断是否跳过
replicate-do-db 和 replicate-ignore-db 的坑在哪？
它们只检查当前 USE 的数据库，不看语句里显式写的库名。比如 USE test; INSERT INTO prod.users VALUES (...); 会被 replicate-do-db=test 放行，但实际写进了 prod 库——这导致数据不一致。
- 跨库操作（
INSERT INTO other_db.t）完全绕过replicate-*-db判断 - 推荐改用
replicate-wild-do-table或replicate-wild-ignore-table，支持通配符且匹配语句中的全限定名 - MySQL 5.7 起已标记
replicate-*-db为“不推荐”，8.0 文档明确建议避免使用
在线修改时为什么 SHOW REPLICA STATUS 显示 Seconds_Behind_Master 突增？
因为过滤规则变更会触发 SQL 线程重建 relay log 解析上下文，短暂暂停事件应用；如果恰逢主库有积压，延迟就体现出来了。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 这不是错误，是正常行为，通常几秒内恢复
- 若延迟持续增长，检查是否误配了
replicate-wild-ignore-table='%.%'这类全盘忽略规则 - 执行前可用
SELECT COUNT(*) FROM mysql.slave_relay_log_info;确认 relay log 位置未异常跳变
MySQL 5.7 和 8.0 在动态改复制过滤上的关键差异
5.7 不支持 CHANGE REPLICATION FILTER，必须停 SQL 线程 + 手动编辑配置文件 + 重启；8.0.23+ 支持真正在线修改，且可针对不同通道（channel）单独设置。
- 5.7 下唯一“在线”方式是临时用
SET GLOBAL sql_slave_skip_counter = 1跳过单条，但无法持久化、不可逆 - 8.0 中
CHANGE REPLICATION FILTER支持FOR CHANNEL 'xxx'，多源复制场景下必须指定 - 8.0 的过滤规则存储在
mysql.replication_filter表中，重启后自动加载，5.7 则完全依赖配置文件
真正麻烦的不是改哪条命令，而是改完之后要不要验证每张表的数据一致性——尤其当过滤规则涉及库名别名、临时表或分区表时，replicate-wild-* 的通配符边界很容易漏判。
