主从复制中触发器会破坏数据一致性
MySQL 主从复制默认是基于 binlog 的逻辑复制，而触发器在从库执行时可能产生意料之外的副作用。最典型的问题是：主库执行一条
INSERT，触发器自动写入另一张表；从库重放这条语句时，如果也执行触发器，就可能导致重复插入、计数错乱或违反唯一约束。
根本原因在于：触发器属于「语句级副作用」，而 binlog 默认记录的是原始语句（
STATEMENT格式）或行变更（
ROW格式），但都不包含触发器是否该在从库执行的元信息。
STATEMENT模式下，从库会重新执行整个语句 + 触发器，极易引发双写
ROW模式下看似安全，但若触发器修改了其他表（非当前 DML 涉及的表），这些变更不会被记录进 binlog，从库就完全缺失这部分数据 即使关闭从库触发器（
slave_sql_verify_checksum=OFF无效；真正有效的是
sql_log_bin=0或设置
log_bin_trust_function_creators=1配合权限控制，但治标不治本）
如何判断触发器是否被从库执行
关键看从库的
binlog_format和触发器定义中的
SQL SECURITY属性，但更直接的方式是查
SHOW SLAVE STATUS\G中的
Seconds_Behind_Master是否异常跳变，再结合错误日志搜
ERROR 1062、
ERROR 1452等。 在从库执行
SELECT @@sql_log_bin;—— 若为
1，说明触发器默认会被执行（除非显式关掉） 检查触发器定义：
SHOW CREATE TRIGGER xxx;，重点关注
DEFINER用户是否有
TRIGGER权限，以及是否用了
SQL SECURITY DEFINER（从库会以定义者身份执行，权限不足则报错） 临时禁用从库触发器：在从库 session 中执行
SET sql_log_bin = 0;，再执行 DML 测试，但注意这会影响所有 binlog 写入，仅限诊断
安全使用触发器的三个硬性前提
不是不能用，而是必须满足以下全部条件，否则同步风险极高：
主从必须统一使用ROW格式（
binlog_format=ROW），且触发器只操作当前语句涉及的同一张表（比如自增字段补全、状态字段更新） 触发器内部禁止出现
INSERT/UPDATE/DELETE其他表、调用存储函数、访问临时表等「跨表/跨上下文」操作 从库必须设置
replicate_ignore_table或
replicate_wild_ignore_table排除触发器所操作的辅助表（如果真有独立日志表），否则主从表结构或数据量会逐渐偏离
替代方案比硬扛触发器更可靠
业务层写入前预处理、应用内事件监听、或者用
GENERATED COLUMN替代简单计算逻辑，都比依赖触发器稳妥。MySQL 8.0+ 的
DATA CHANGE REPLICATION（DCR）仍不支持触发器透传，所以没有银弹。
最容易被忽略的一点：即使你确认触发器「只读」或「幂等」，只要它访问了主库存在但从库缺失的表（比如监控表、配置表），就会导致从库 SQL 线程直接停止——错误信息通常是
Table 'xxx.yyy' doesn't exist，而不是触发器本身报错。
