mysql 8.0.23+ 支持真正在线修改复制过滤规则，5.7 需停启 sql_thread 才生效；所有版本均不支持 set global 自动重载，且 replicate-wild-ignore-table 是唯一可靠方案。
CHANGE REPLICATION FILTER 在 MySQL 8.0.23+ 中可真正在线执行，但 5.7 只能停 SQL 线程后修改，且所有版本都不支持 SET GLOBAL 修改后自动生效——这是最常踩的坑。
MySQL 5.7 必须 STOP/START SQL_THREAD 才能加载新规则
5.7 不支持 CHANGE REPLICATION FILTER 的“热生效”，即使你执行了该语句，SQL 线程仍沿用旧过滤逻辑，直到重启。常见误操作是：
- 执行
CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db1.log_%');后直接查SHOW SLAVE STATUS\G，发现Replicate_Wild_Ignore_Table没变——其实是没生效，不是显示问题 - 漏掉
STOP SLAVE SQL_THREAD，导致命令报错ERROR 3017 (HY000)，但误以为参数写错了 - 只停
SLAVE（即同时停 IO 和 SQL），造成主从延迟突增；正确做法是仅停SQL_THREAD，让 IO 线程继续拉取 binlog
完整流程必须是：
STOP SLAVE SQL_THREAD;CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db1.log_%');START SLAVE SQL_THREAD;
MySQL 8.0.23+ 的 CHANGE REPLICATION FILTER 是真在线，但有边界
它不需要停线程，执行即刻对后续 relay log 事件生效，但要注意：
- 已拉取、未执行的 relay log 仍按旧规则处理——这意味着刚改完规则时，可能看到几条本该被忽略的日志还在同步
- 若使用多源复制，必须显式指定
FOR CHANNEL 'xxx'，否则默认作用于''（空通道） - 规则变更会触发 SQL 线程短暂重建解析上下文，
Seconds_Behind_Master可能瞬时跳升，属正常现象 - 修改后立即查
SELECT * FROM mysql.replication_filter;可确认是否入库成功（5.7 没这张表）
为什么 replicate-wild-ignore-table 是唯一推荐的在线方案
其他参数如 replicate-ignore-db 或 replicate-do-db 在 ROW 格式下基本不可靠，原因很实际：
- 它们只检查客户端当前
USE的库，不看 SQL 里写的全限定名。比如USE test; INSERT INTO prod.users VALUES ();，哪怕replicate-ignore-db = test，数据照样进从库的prod库 -
replicate-wild-ignore-table直接匹配事件中的db_name.table_name字符串，不受USE或复制格式影响 - 通配符只支持
%和_，库名含下划线需转义：写成app\_db.%，否则app_db.%会被当成 “app任意字符b.%” - ROW 模式下库名大小写敏感，主从
lower_case_table_names值必须一致，否则MyDB.%匹配不上mydb.t1
验证是否真的生效，不能只看 SHOW VARIABLES
SHOW VARIABLES LIKE 'replicate%' 显示新值，不代表行为已变。真正验证要分两步：
- 在主库写一条明确命中过滤规则的语句，例如：
INSERT INTO db1.log_20260614 VALUES (1, NOW()); - 立刻查从库对应表：
SELECT COUNT(*) FROM db1.log_20260614;—— 如果返回0且无新增记录，才算真正生效 - 别忘了检查
SHOW SLAVE STATUS\G中的Slave_SQL_Running_State是否卡在Reading event from the relay log，这说明过滤器初始化失败，可能是通配符语法错误或权限不足
最麻烦的不是命令怎么敲，而是改完之后要不要立刻校验每张被过滤表的数据一致性——尤其当规则涉及分区表、临时表或跨库写入场景，这些地方容易漏匹配。
