binlog_format=ROW是解决触发器不一致最直接有效的手段，但需主从均配置、禁用SQL_LOG_BIN绕过、关闭IDEMPOTENT模式，并排查非确定性函数、临时表、存储过程等残留风险，否则仍可能不一致。
binlog_format=ROW 是解决 MySQL 主从复制中触发器不一致最直接有效的手段，但不是“一设就灵”，必须配合验证和配置检查。
为什么 Statement 模式下触发器容易不一致
在 binlog_format=STATEMENT 下，MySQL 只记录原始 SQL（比如 INSERT INTO t1 ...），不记录触发器实际执行的变更。从库重放时，如果触发器逻辑依赖会话变量、函数（如 NOW()、USER()、UUID()）或主库特有状态，结果很可能与主库不同。
常见现象包括：
- 从库某张表多出/少了几行数据，但主库
SHOW BINLOG EVENTS看不到对应语句 -
SELECT COUNT(*)在主从上结果不一致，且差异稳定复现 - 触发器更新了另一张表，但从库那张表没变，或更新值错误
切换到 ROW 模式前必须确认的 4 件事
binlog_format=ROW 要生效，不只是改配置那么简单：
- 主库和从库都必须显式设置
binlog_format=ROW（不能只设主库）；否则从库仍按 STATEMENT 解析 relay log，触发器逻辑照样丢失 - 修改后需重启 MySQL 或执行
SET GLOBAL binlog_format='ROW'，但后者仅对新连接生效，已有连接仍用旧格式，建议重启 - 确认当前所有复制通道（尤其是多源复制）没有被
SET SQL_LOG_BIN=0绕过，否则即使 ROW 模式也无日志可同步 - 检查从库是否启用了
slave_exec_mode=IDEMPOTENT—— 它会让某些重复写入失败，掩盖触发器未执行的问题，应设为STRICT
切完 ROW 后仍不一致？重点查这 3 类触发器
即便用了 ROW 模式，以下情况仍会导致主从数据偏差：
- 触发器里调用了非确定性函数：
RAND()、UUID()、SYSDATE()—— ROW 模式只记录最终行变更，不保证这些函数在从库重放时结果相同 - 触发器访问了临时表或用户变量（
@var）：这些在从库不存在，执行会静默失败或报错（取决于slave_sql_verify_checksum和错误处理策略） - 触发器内嵌了存储过程，而该过程含
SELECT ... INTO或游标操作：ROW 模式不捕获中间查询结果，只记录最终 DML 行变更，逻辑链断裂
这类问题无法靠换 binlog 格式解决，必须重构触发器，把非确定性逻辑移到应用层，或改用明确的常量/时间戳传参。
验证触发器是否真正同步的实操方法
别只看 Seconds_Behind_Master=0，要确认触发器行为本身被正确复制：
- 在主库插入一条能触发目标触发器的数据，立即查主库被影响的关联表；等从库
Seconds_Behind_Master归零后，立刻查从库同一张表 —— 必须逐字段比对 - 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.0000xx | grep -A 5 -B 5 "your_table_name"确认 binlog 中是否真有触发器产生的行变更事件（而非只有原始 INSERT） - 开启从库
log_slave_updates=ON并在从库上开一个新从库（级联），观察二级从库是否也出现同样偏差 —— 如果二级也一致，说明问题不在复制链路，而在触发器逻辑本身
最容易被忽略的是：触发器在主库执行成功，但从库因权限不足（比如缺少对触发器中涉及表的 SELECT 权限）而静默跳过。务必检查从库 error log 中是否有 Table 'xxx' doesn't exist 或 Access denied 类警告。
