MySQL触发器在STATEMENT复制模式下会导致主从不一致，因主库执行触发器后，从库重放SQL时再次触发，造成逻辑重复执行；必须改用ROW模式，且避免在触发器中使用UUID()、NOW()等非确定性函数。
MySQL触发器在STATEMENT复制模式下会引发主从不一致
触发器在主库执行时会“额外触发”一次，而从库根据binlog重放SQL时又会再执行一遍——等于同一逻辑被执行两次。根本原因是STATEMENT模式只记录原始SQL（比如INSERT INTO orders），不记录触发器内部动作，导致从库无法跳过触发逻辑。
常见错误现象：SLAVE_SQL_RUNNING: No，报错Duplicate entry或Cannot add or update a child row；或者数据行数、字段值明显对不上。
- 必须改用
ROW复制模式（binlog_format = ROW），这是唯一能保证触发器行为被正确同步的方案 -
MIXED模式不可靠：MySQL自动降级到STATEMENT时，触发器仍会出问题 - 修改后需重启MySQL或执行
SET GLOBAL binlog_format = 'ROW'，并确认所有从库已同步该配置 - 已有主从延迟场景下，切模式前先停写、等追平，否则可能丢事件
触发器里调用UUID()或NOW()会导致主从时间/值不一致
这类函数在主库和从库执行时刻不同，返回值天然不同。ROW模式虽能记录变更后的值，但前提是触发器本身不依赖运行时上下文——而UUID()每次调用都生成新值，NOW()取的是本地系统时间。
使用场景：审计字段自动填充（如created_at、trace_id）。
- 避免在触发器中直接调用
UUID()，改用NEW.trace_id := UUID()仅在INSERT前赋值一次 -
NOW()应替换为SYSDATE()？不行——它同样返回执行时刻时间；正确做法是显式传入时间戳，或由应用层生成后写入 - 若必须用时间函数，确保主从系统时钟已用
chrony严格同步（误差SYSDATE()或NOW()差异会被放大
从库上禁用触发器不能解决一致性问题
有人试图在从库执行SET SQL_LOG_BIN = 0; DROP TRIGGER ...或干脆关掉触发器，这反而破坏复制链路——主库的变更仍会写入binlog，从库跳过触发器后，数据状态与主库语义脱节。
典型后果：主库某字段由触发器自增，从库没触发→该字段始终为NULL或默认值→后续JOIN或WHERE条件失效。
- 从库触发器必须保留，且定义需与主库完全一致（包括
DELIMITER、字符集、注释） - 检查一致性可用
SHOW CREATE TRIGGER对比主从输出，注意DEFINER用户是否存在，否则从库可能加载失败 - 部署新触发器时，务必先在从库创建，再在主库创建，避免主库写入触发而从库无对应逻辑
触发器嵌套+复制延迟会放大竞态风险
一个触发器更新另一张表，又触发第二个触发器，这种链式反应在主库是原子完成的，但从库上因延迟存在时间差，中间状态可能被其他并发线程读到——尤其当业务代码假设“触发器保证了某约束”时，实际从库上这个约束有短暂窗口不成立。
性能影响：每层触发器都增加binlog写入体积和从库SQL线程解析开销，ROW格式下还可能让单条语句产生多行变更记录。
- 尽量扁平化逻辑，把嵌套触发器合并成单个，减少binlog事件数量
- 对强一致性要求的字段（如库存、余额），不要依赖触发器兜底，应在应用层加分布式锁或用
SELECT ... FOR UPDATE - 监控
Seconds_Behind_Master，超过阈值时主动告警，而不是默认信任“最终一致”
最麻烦的不是触发器写得对不对，而是它在主从之间“看起来一样、跑起来不一样”——时间函数、用户变量、临时表、存储过程调用，全都会在ROW模式下暴露隐含依赖。上线前必须用真实流量压测主从数据比对。
