主从触发器重复执行的根源是STATEMENT复制模式下从库二次执行触发器，须确保主从binlog_format均为ROW，并禁用非确定性函数及跨表操作。
主从触发器重复执行的典型现象
主库一条INSERT，从库对应表多出两行；主库UPDATE后字段值正确，从库该字段却是默认值或NULL；SHOW SLAVE STATUS\G里Seconds_Behind_Master跳变剧烈，但Slave_SQL_Running仍为Yes；错误日志频繁出现ERROR 1062（主键冲突）或ERROR 1452（外键失败）。这些不是偶然写错，而是触发器在主库执行一次、从库又执行一次的明确信号。
确认是否处于STATEMENT复制模式
这是90%重复执行的根源。binlog_format=STATEMENT下，MySQL只记原始SQL，不记触发器动作。从库重放时，不管主库是否已触发，它都会再跑一遍触发器逻辑。
- 分别在主库和从库执行：
SELECT @@binlog_format;——两处都必须返回'ROW'，缺一不可 - 如果返回
'STATEMENT'或'MIXED'，立刻处理：SET GLOBAL binlog_format = 'ROW';后重启MySQL（仅SET对已有复制线程无效） -
MIXED不可信：MySQL可能自动降级到STATEMENT，尤其遇到UUID()、NOW()等函数时
检查触发器是否被从库实际执行
即使开了ROW模式，从库仍可能静默执行触发器——只要@@sql_log_bin = 1且触发器定义存在。
- 在从库执行：
SELECT @@sql_log_bin;——必须是1，否则SET SQL_LOG_BIN = 0已关闭日志，整个复制链就断了 - 对比主从触发器定义：
SHOW CREATE TRIGGER trigger_name;，注意DEFINER用户是否存在、权限是否完整（尤其是TRIGGER权限） - 临时验证：在从库开启新会话，
SET sql_log_bin = 0;，再手动INSERT一条能触发的数据，查关联表是否变化——若不变，说明原触发器确实在执行
排查非确定性函数与跨表操作
ROW模式能记录最终变更，但无法保证触发器内部逻辑在主从上结果一致。
- 禁止在触发器中调用
UUID()、NOW()、SYS_DATE()、RAND()——主从执行时刻不同，值必然不同 - 避免触发器更新其他表（如统计表、日志表）：
ROW只记录当前DML涉及的表变更，跨表操作不会进binlog，从库完全缺失这部分数据 - 禁用
USER()、CURRENT_USER()：DEFINER用户在从库可能不存在，或会话上下文不同导致返回值错乱 - 不要依赖
@user_var或临时表：从库没有主库的会话变量状态，这类操作会静默失败
真正难排查的点不在配置开关，而在触发器代码本身——它看起来只改一行，却偷偷调用了存储过程、读了未索引的大表、或嵌套了另一个触发器。每次怀疑重复，先盯住触发器body里有没有INSERT/UPDATE非当前表、有没有函数调用、有没有SELECT ... INTO。这些才是让ROW模式也救不了的硬伤。
