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 这类隐式依赖其他表的操作——这些都会在某次低峰期批量导入后突然暴露不一致。
