STATEMENT模式下触发器导致主从数据不一致，因从库重放sql时重新执行触发器，使NOW()、UUID()、子查询等结果与主库不同；ROW模式可避免二次触发，但需注意log_slave_updates、非确定性函数、DDL变更及自增冲突等问题。
mysql触发器在STATEMENT复制模式下会引发数据不一致
触发器本身不是问题，问题出在它和复制模式的交互上。在binlog_format = STATEMENT时，主库只记录原始sql语句（比如INSERT INTO orders ...），从库重放这条语句时，会再次执行触发器——但此时触发器里的NEW/OLD值、函数（如NOW()、UUID()、USER()）或子查询结果可能和主库执行时完全不同。
常见错误现象包括：
- 从库多插入/少插入一行（比如触发器里又
INSERT INTO log_table，主库一次操作触发两次写入，从库可能触发三次或零次） -
UUID()或NOW()在主从生成不同值，导致校验失败 - 触发器依赖
select ... FROM other_table，而该表在从库上尚未同步到位，查到空值或旧数据
ROW格式能规避大部分触发器同步风险，但有例外
binlog_format = ROW时，主库记录的是行变更前后的镜像（Before Image和After Image），从库直接应用这些变更，**不重新执行触发器**——这是关键。因此绝大多数场景下，触发器在主库执行一次，从库不会二次触发，数据一致可保障。
但要注意这些例外：
- 从库启用了
log_slave_updates = ON且自身也是其他实例的主库时，它的二进制日志仍按ROW格式记录，下游再同步依然安全；但如果下游是STATEMENT模式，风险回归 - 触发器内调用
GET_LOCK()、SLEEP()等非确定性函数，虽不改变同步结果，但会导致主从执行耗时不一致，影响延迟监控判断 - DDL操作（如
ALTER TABLE）导致触发器被重建，若主从表结构未严格同步，触发器可能失效或报错Error 1356 (HY000): View 'xxx' references invalid table(s) or column(s)
触发器+自增字段+主从切换可能引发主键冲突
如果触发器在BEFORE INSERT中手动设置NEW.id = some_function()，而该函数逻辑依赖时间戳或随机数，就可能绕过InnoDB的自增锁机制。更危险的是：当使用AUTO_INCREMENT列 + INSERT ... ON DUPLICATE KEY UPDATE时，主库因触发器干预导致自增值跳变，从库在重放ROW事件时虽不执行触发器，但auto_increment_offset和auto_increment_increment若配置不对（尤其在双主或多源复制中），切换后新写入极易触发Duplicate entry 'X' for key 'PRIMARY'。
实操建议：
- 避免在触发器中显式赋值
AUTO_INCREMENT列 - 所有涉及自增的集群，统一设置
auto_increment_offset和auto_increment_increment，例如双主部署设为offset=1, increment=2和offset=2, increment=2 - 用
SHOW VARIABLES LIKE 'auto_inc%';定期核对主从是否一致
替代触发器的更安全方案：应用层处理或存储过程封装
真正需要强一致的业务逻辑（比如订单创建后必须同步生成流水、扣减库存、发通知），靠触发器+复制很难兜底。不如把这类逻辑收口到应用层事务中，或用存储过程封装成原子操作：
DELIMITER $$ CREATE PROCEDURE create_order_with_log( IN p_user_id INT, IN p_amount DECIMAL(10,2) ) BEGIN DECLARE v_order_id BIGINT DEFAULT 0; START TRANSACTION; INSERT INTO orders(user_id, amount) VALUES(p_user_id, p_amount); SET v_order_id = LAST_INSERT_ID(); INSERT INTO order_logs(order_id, action) VALUES(v_order_id, 'created'); COMMIT; END$$ DELIMITER ;这样整个流程在单条CALL create_order_with_log(...)中完成，无论STATEMENT还是ROW格式，主从都只同步这一条CALL语句或对应行变更，没有触发时机偏差问题。
真正容易被忽略的是：很多团队以为只要开了ROW格式就万事大吉，却忘了检查slave_type_conversions是否为空、replicate_do_table有没有漏配、以及触发器本身是否包含INSERT ... SELECT这类隐式依赖其他表的操作——这些都会在某次低峰期批量导入后突然暴露不一致。