ROW模式无法保证触发器中NOW()、UUID()等非确定性函数的一致性，因其只记录变更后的行数据而非执行逻辑；STATEMENT模式下触发器根本不复制；MIXED模式也可能降级为STATEMENT；触发器更新同表字段在从库易因重放顺序错乱导致覆盖；GTID下更难定位问题；语义偏移难以发现，需行级比对或迁移到应用层。
触发器调用NOW()、UUID()等函数时，ROW模式也保不住一致性
很多人误以为只要把 binlog_format 改成 ROW，触发器里的非确定性函数就“安全”了。事实不是这样。比如主库触发器里写了 NEW.created_at := NOW()，从库重放时照样会用从库本地时间生成新值——ROW 模式只记录“哪一行被改成什么样”，不记录“为什么这么改”。
排查方法很简单：SHOW CREATE TRIGGER trigger_name，然后人工搜 UUID(、NOW(、SYS_DATE(、RAND( 这类调用。
- 正确做法是：应用层生成好时间戳或 ID 后作为参数传入，或让 MySQL 自动填充（
NEW.field := DEFAULT(field)，前提是字段定义了DEFAULT） - 若必须依赖时间，主从系统时钟误差需控制在毫秒级，
chrony同步是底线，NTP 不够稳 - 哪怕只是
ROW_COUNT()或USER()这种看似无害的函数，只要出现在触发器逻辑分支里，就可能因执行上下文差异导致从库更新错行
Statement格式下触发器根本不会被复制
STATEMENT 格式只记录原始 SQL 语句本身，不记录触发器是否被触发、触发几次、触发后又干了什么。比如主库执行一条 INSERT INTO t1 ...，触发器顺带往 t2 插了一条记录，但从库只重放那条 INSERT INTO t1，t2 完全没变——数据直接裂开。
这种问题在 SHOW SLAVE STATUS 里往往不报错，因为 SQL 执行成功了，只是结果不对。你得靠定期校验（比如 pt-table-checksum）才能发现。
- 不要试图在
STATEMENT模式下依赖触发器做关键逻辑，尤其是跨表写入 - 如果必须用
STATEMENT（比如旧系统兼容），至少确保所有触发器逻辑都可被主键+条件精确还原，且不依赖运行时状态 -
MIXED模式也不是万能的：MySQL 对“是否确定”的判断有时不准，仍可能降级为STATEMENT记录触发器相关操作
触发器更新同一张表时，从库重放顺序可能错乱
主库上触发器更新本表另一字段（比如插入用户时自动设 status = 'active'），看起来很安全。但在从库，SQL 线程是单线程串行重放 relay log 的，而主库上触发器执行和原语句属于同一个事务，但重放时它们被拆成了两条独立事件——中间可能插入其他事务的变更，导致字段更新被覆盖或错序。
典型现象是：主库某行最终值为 status='active', updated_at='2026-05-18 11:30:00'，从库变成 status='pending', updated_at='2026-05-18 11:30:00'（触发器更新被后来的 UPDATE 覆盖）。
- 避免在触发器里更新当前表的非主键字段；如必须，改用应用层统一处理
- 如果用了 GTID，注意
gtid_next是按事务分配的，触发器内联的更新无法单独跳过，修复时更难定位 - 这类问题在高并发写入 + 复制延迟场景下爆发概率极高，且日志里查不到错误，只能靠行级比对
真正难排查的是“触发器没报错，但语义偏移”
最麻烦的不是语法错误或主键冲突，而是触发器逻辑在从库执行时“没错，但不对”。比如触发器根据 OLD.status 和 NEW.amount 做判断，主库事务提交前这些值是确定的，但从库 relay log 里只存了最终 NEW 行像，OLD 值丢失了，触发器实际运行时拿不到原始上下文。
这种偏移无法通过 SHOW SLAVE STATUS 或错误日志发现，只有当业务侧出现“明明改了A字段，B字段却没联动更新”这类现象时才可能暴露。
- 别指望
ROW模式兜底所有触发器场景——它只保证数据快照一致，不保证执行路径一致 - 生产环境若已大量使用触发器，建议逐步迁移到应用层，或至少把核心逻辑抽成存储过程+显式调用，便于控制复制行为
- 测试阶段一定要用真实主从环境跑触发器路径，仅本地单实例验证毫无意义
