MySQL 主从同步怎么跳过某个表的复制
想让从库对主库的某张表“视而不见”？核心方法是在从库的 my.cnf 配置文件中，设置 replicate-ignore-table 或 replicate-wild-ignore-table 参数。这里有个关键点：配置完成后，必须重启 mysqld 服务才能生效，动态的 SET 命令在这里是无效的。
一个常见的误区是，直接在从库执行类似 SET GLOBAL replicate_ignore_table = ‘db1.t1’; 的命令。这完全行不通，因为这类变量是只读的，MySQL 本身就不支持在运行时动态修改复制过滤规则。
replicate-ignore-table：用于精确匹配。格式必须是db_name.table_name，大小写是否敏感取决于系统变量lower_case_table_names的设置。replicate-wild-ignore-table：支持通配符，比如db1.log_%或test.%，灵活性更高，因此也更常用。- 忽略多张表？ 需要写多行配置，每行一个，不能用逗号分隔。
- 验证生效：配置重启后，可以通过
SHOW SLA VE STATUS\G命令，查看Replicate_Ignore_Table字段是否已更新。
为什么 replicate-do-db 和 replicate-ignore-db 很容易出错
这两个基于数据库名的过滤规则，其行为逻辑有点“反直觉”。它们判断的依据，是 SQL 线程当前正在使用的数据库（即 USE 语句指定的库），而不是 SQL 语句中显式写明的库名。
举个例子：主库执行 INSERT INTO db1.t1 …，但如果执行这条语句时，SQL 线程的当前库不是 db1（甚至是空），那么这条语句就可能被意外地放过或拦截。真正安全的场景极少，除非所有应用程序都严格遵守“先 USE db_x，再执行语句”的规范——这在现实中几乎不可能。
- DDL 语句同样受影响：像
CREATE TABLE db1.t2这样的操作，也会因为当前数据库的判断问题，导致replicate-ignore-db规则不可靠。 - GTID 的隐患：如果启用了 GTID，使用这些基于库/表名的过滤规则，可能导致主从双方的
gtid_executed和gtid_purged集合不一致，为后续的主从切换埋下隐患。 - 最佳实践：优先使用
replicate-wild-ignore-table，明确指定到表级别，行为更可预测。
从库已同步了不该同步的表，现在想补救
需要明确一点：复制过滤规则只对配置生效后新产生的复制事件起作用，它不会自动删除从库上已经存在的数据。如果那张表的数据已经被同步过来了，就需要手动介入清理。
- 第一步，停止复制：执行
STOP SLA VE;。 - 第二步，安全删除：确认从库的这张表没有业务写入（否则会导致数据丢失），然后执行
DROP TABLE db1.t1;。 - 第三步，重启复制：执行
START SLA VE;。此后，主库对该表的所有变更都不会再同步到从库。 - 一个后续风险：如果主库后续执行了
DROP DATABASE或TRUNCATE TABLE等涉及该表的操作，从库会因为表不存在而报错（Table doesn‘t exist）。此时需要人工干预，例如使用SET GLOBAL sql_sla ve_skip_counter = 1;或通过gtid_next来跳过这个特定事务。
使用 replicate-wild-ignore-table 时的路径陷阱
通配符匹配的是 SQL 语句中间出现的库名和表名，而不是磁盘上的文件路径。不过，要特别注意下划线、点号这些字符的语义——MySQL 的 wild-ignore 采用的是简单的 shell 风格通配符，并非正则表达式。
- 忽略带日期的表：想忽略
log_20240101这类表？写成db1.log_*即可，这里的下划线_就是普通字符，无需转义。 - 正确使用通配符：想忽略
db1.user_info和db1.user_settings？用db1.user_*。注意，不要写成db1.user%，因为在 shell 通配规则里，%在这里只是一个普通字符，不是通配符。 - 格式注意：配置值里不能包含空格。像
replicate-wild-ignore-table = db1.t1 , db1.t2这样的写法会导致解析失败，必须换行或去掉空格。 - 大小写敏感：在 Linux 系统下默认是区分的，
DB1.T1和db1.t1会被视为两个不同的匹配目标。
MySQL主从同步中跳过某表复制需在从库my.cnf配置replicate-ignore-table或replicate-wild-ignore-table并重启mysqld；动态SET无效，过滤仅作用于SQL线程重放阶段，不删除已同步数据。
最后，有一个非常重要的机制需要理解：过滤规则仅作用于 SQL 线程的重放阶段。这意味着，主库的 binlog 事件仍然会被完整地传输到从库，并写入 relay log 中，只是在应用（执行）时被跳过了。所以，磁盘空间（Relay_Log_Space）的占用并不会减少，在排查复制延迟问题时，这一点很容易造成误判。
