MySQL 多条复制过滤规则按什么顺序生效

MySQL 多条复制过滤规则不是按配置文件从上到下覆盖。固定顺序是：先应用 replicate-rewrite-db，再判断库级 replicate-do-db / replicate-ignore-db，通过后才进入表级判断；表级依次检查精确 do、精确 ignore、通配 do、通配 ignore。某一层得到“执行”或“忽略”的终局结果后，就不会再让后面的规则把它翻转。

本文依据 MySQL 8.4 官方手册的复制过滤规则说明整理，原始地址：https://dev.mysql.com/doc/refman/8.4/en/replication-rules.html。

把复制过滤理解成分层门禁

复制线程拿到事件后，先确认源端是否写入了二进制日志；源端没有记录的语句，副本自然无从复制。事件到达副本后，过滤链才开始工作。完整的主线可以压缩为下面三层：

1. 库名改写层：replicate-rewrite-db 先把当前数据库名映射成新名字，后续规则基于改写后的结果继续判断。
2. 库级过滤层：先看所有 replicate-do-db，没有 do 规则时再用 replicate-ignore-db 排除。
3. 表级过滤层：只有库级没有给出拒绝结果，或者库级明确允许继续时，才检查四类表规则。

这里最容易犯的错，是把 do 理解成普通 allowlist、把 ignore 理解成普通 denylist，然后假设“更具体的规则总能覆盖更宽泛的规则”。MySQL 实际采用的是固定检查顺序和命中退出逻辑，配置项的具体程度并不会自动改变优先级。

库级规则：先 do，再 ignore

如果配置了一个或多个 replicate-do-db，事件必须匹配其中任意一个，才会继续进入表级判断；一个都不匹配时，事件直接被忽略。只有完全没有 replicate-do-db 时，才轮到 replicate-ignore-db：匹配任意 ignore 就忽略，不匹配则继续。

“当前库”并不总是同一个概念。语句格式下，DML 依据 USE 选中的默认库判断，即使 SQL 写成 INSERT INTO db2.t VALUES (...)，默认库仍可能是 db1。行格式下，DML 根据真正被修改的表所在库判断。DDL 始终以语句方式过滤，因此仍受默认库影响。

表级规则的精确顺序

进入表级过滤后，MySQL 依次检查下面四组规则。对每一组而言，只要目标表匹配其中任意一条，就立即执行对应动作并退出本轮判断：

1. replicate-do-table：精确匹配，命中则执行。
2. replicate-ignore-table：精确匹配，命中则忽略。
3. replicate-wild-do-table：通配匹配，命中则执行。
4. replicate-wild-ignore-table：通配匹配，命中则忽略。

四组都没有命中时，还有一个关键兜底：只要配置中存在任何精确 do 或通配 do，事件就被忽略；如果完全没有表级 do 规则，则事件执行。也就是说，do 规则一旦出现，未命中的对象默认落到“拒绝”；只有 ignore 规则时，未命中的对象默认通过。

冲突案例：为什么看起来“排除失效”

假设希望复制 sales 库全部表，但排除 sales.audit_log，却写成下面这组规则：

# 精确 do 规则最先检查，命中后立即执行。
replicate-do-table = sales.audit_log

# 通配 ignore 排在精确 do 之后，无法翻转前面的执行结果。
replicate-wild-ignore-table = sales.audit_%

对 sales.audit_log 来说，第一组精确 do 已经命中，后面的通配 ignore 根本不会执行。若实际目标是“复制 sales 的大多数表，只排除一张”，更清晰的组合是：

# 没有表级 do 规则时，未被排除的表默认执行。
replicate-ignore-table = sales.audit_log

如果还要限定只处理 sales，可以使用库级 allowlist 再配表级排除，但必须接受库级语义受日志格式影响。对需要跨格式保持一致的场景，官方更建议只用表级规则，并避免一条多表 DML 同时更新“允许”和“忽略”的表。

动态调整时怎样写得更可控

MySQL 支持通过 CHANGE REPLICATION FILTER 为复制通道调整过滤规则。下面仅展示规则结构；执行前应先确认通道名、当前拓扑和维护窗口：

-- 为 channel_1 设置库级允许和表级精确排除。
CHANGE REPLICATION FILTER
  REPLICATE_DO_DB = (sales),
  REPLICATE_IGNORE_TABLE = (sales.audit_log)
FOR CHANNEL 'channel_1';

不要用重复执行命令来“猜”最终配置。先把每一类规则列成清单，再按固定优先级推演代表事件。尤其要同时准备 DML、DDL、带显式库名的语句和多表操作四类样本，因为它们观察数据库名的方式并不相同。

上线前观察哪些信号

• 规则命中边界：分别记录允许样本、拒绝样本以及未命中样本的预期结果。
• 日志格式：确认源端实际使用 ROW、STATEMENT 还是 MIXED，不要只看历史配置。
• DDL 默认库：核对建表、改表、删库语句执行前的 USE 上下文。
• 多表副作用：关注触发器、级联外键、存储函数和多表更新，避免同一语句横跨过滤边界。
• 通道隔离：多源复制时按通道核对规则，防止把一条通道的预期套到另一条通道。

相关问题

同一种过滤规则写多条，后写的会覆盖前写的吗

不会。判断时会检查这一类型下的全部规则，匹配任意一条就算命中。真正决定优先级的是规则类型，而不是文本出现位置。

replicate-ignore-db 能否被 replicate-do-table 覆盖

不能。库级 ignore 一旦命中，事件直接被忽略，表级 do 不会获得检查机会。

只配置 ignore-table 时，其他表会怎样

其他表默认执行。只有出现至少一条表级 do 规则时，所有没有命中 do 的表才默认忽略。

ROW 模式下 DDL 也按实际表所在库判断吗

不是。DDL 始终按语句过滤，默认库仍然重要；ROW 模式改变的主要是 DML 行事件的判断对象。