触发器不能实现主从数据过滤，仅在单实例内生效；主从过滤必须通过从库的replicate_do_db、replicate_wild_ignore_table等参数控制SQL线程回放行为。
触发器不能在主从架构下实现“主从间的数据过滤”——它只在单个实例内生效，对复制过程本身无影响。所谓“通过触发器实现主从过滤”，本质是误解：触发器运行在主库（或从库）本地，它能做的只是阻止某条 INSERT 或 UPDATE 执行，但不会改变 binlog 内容，也不会让从库跳过同步。
为什么触发器对主从复制无效
MySQL 主从复制依赖 binlog 事件，而触发器是在 SQL 执行阶段介入的逻辑层。即使你在主库定义了 BEFORE INSERT 触发器并用 SIGNAL 中断插入，该中断只发生在主库语句执行时；如果语句已成功写入 binlog（比如没被触发器拦住），那它仍会原样传到从库执行。反过来，如果你在从库加触发器，它只影响从库本地写入，与主库无关，也无法控制“哪些数据该同步”。
- 触发器不修改 binlog 内容，也不影响 IO 线程拉取或 SQL 线程回放逻辑
- 主库触发器拦住的数据，根本不会进入 binlog，自然也不会同步——但这不是“过滤同步”，而是“没产生同步源”
- 从库触发器拦住的数据，会导致 SQL 线程报错、停止复制（
Slave_SQL_Running: No），属于故障态，不是可控过滤
真正影响主从同步的过滤点只有两个位置
主从数据流是：主库写 binlog → 从库 IO 线程拉取 → 写 relay log → 从库 SQL 线程回放。过滤只能发生在这条链路上的两个环节：
-
主库端：用
binlog-do-db或binlog-ignore-db控制哪些库的操作写入 binlog（需重启 MySQL，且不推荐，破坏 binlog 完整性） -
从库端：用
replicate_do_db、replicate_wild_ignore_table等参数控制 SQL 线程是否回放某类事件（推荐方式，灵活且安全）
例如，要忽略所有日志表同步，应在从库配置中写：
replicate_wild_ignore_table = 'db1.log_%'<br>replicate_wild_ignore_table = 'mysql.%'<br>replicate_wild_ignore_table = 'sys.%'
这类规则对 INSERT INTO db1.log_01 和 UPDATE db1.log_02 都生效，且无需重启 mysqld（改完后执行 STOP SLAVE IO_THREAD; START SLAVE IO_THREAD; 即可）。
误用触发器替代复制过滤的典型后果
有人试图在从库加触发器拦截特定业务数据（比如不让 status = 'deleted' 的记录落地），这会导致：
- SQL 线程遇到
SIGNAL报错，Seconds_Behind_Master持续增长，Slave_SQL_Running变为No - 错误信息类似：
ERROR 1644 (45000): 用户状态不合法，但这个错误不会自动跳过，必须人工SET GLOBAL sql_slave_skip_counter = 1或用gtid_next跳过，极易丢数据 - 触发器逻辑无法覆盖 DDL（如
DROP TABLE）、批量操作（LOAD DATA）或存储过程内部变更
真正需要“主从间数据过滤”，就老实用从库的 replicate_* 规则；触发器只适合单实例内的业务校验，混用只会把问题从应用层推到复制层，更难定位。
