statement模式下触发器必然不一致，因其仅记录原始sql（如insert into orders），不记录触发器内部执行的update inventory或insert log_audit等操作，导致从库重放时触发器逻辑完全丢失；典型现象包括主从count(*)结果不同、被触发修改的表无变化、now()/user()字段为null或默认值；切换row模式前须同时满足主从均设binlog_format=row、重启mysql或确保新连接生效、禁用set sql_log_bin=0、slave_exec_mode设为strict；即便启用row模式，若触发器含rand()/uuid()/sysdate()、访问临时表或用户变量、调用含select into或游标的存储过程，仍会导致主从偏差，必须重构逻辑；验证需在主库插入触发数据后，逐字段比对主从所有关联表结果。
为什么STATEMENT模式下触发器必然不一致
因为binlog_format=STATEMENT只记录原始SQL，比如INSERT INTO orders，不记录触发器内部执行的UPDATE inventory或INSERT log_audit。从库重放时，触发器逻辑完全丢失——哪怕主库触发器更新了5张表，从库只执行了最外层那一条语句。
典型现象包括：Last_SQL_Error没报错但SELECT COUNT(*)主从结果不同；某张被触发器修改的表在从库完全没变化；触发器里用了NOW()或USER()，从库写入的时间戳或操作人字段全是NULL或默认值。
切ROW模式前必须验证的4个硬性条件
只改binlog_format=ROW配置文件重启，大概率无效：
- 主库和从库都必须显式设置
binlog_format=ROW，不能只设主库——否则从库SQL线程仍用STATEMENT解析relay log - 执行
SET GLOBAL binlog_format='ROW'后，已有连接仍沿用旧格式，必须重启MySQL或确保所有新连接生效 - 检查是否有人在主库执行过
SET SQL_LOG_BIN=0，这类语句绕过binlog，ROW模式也捕获不到 - 确认从库
slave_exec_mode是STRICT而非IDEMPOTENT，后者会静默忽略重复插入，掩盖触发器未执行的事实
即使开了ROW模式，这3类触发器仍会出问题
binlog_format=ROW能解决90%的触发器不一致，但以下情况它无能为力：
- 触发器调用
RAND()、UUID()、SYSDATE()：ROW只记录最终行变更，不保证这些函数在从库重放时结果相同 - 触发器访问临时表或用户变量（如
@tmp_id）：从库没有这些上下文，执行直接失败或跳过 - 触发器内调用存储过程，且过程含
SELECT ... INTO或游标：ROW不记录中间查询结果，只记最终DML，逻辑链断裂
这类问题无法靠配置修复，必须重构：把UUID()换成应用层生成并传参；把临时表逻辑拆到应用侧；用明确的CURRENT_TIMESTAMP替代SYSDATE()。
验证触发器是否真正同步的实操方法
别只看Seconds_Behind_Master=0，要验证行为本身：
- 在主库插入一条能触发目标触发器的数据，立即查主库被影响的所有关联表（比如订单表+库存表+日志表）
- 等从库
Seconds_Behind_Master回到0后，立刻在从库查同样几张表——必须逐字段比对，尤其注意时间戳、计数器、状态字段 - 如果某张表数据没变，或字段值明显不合理（如库存减成了负数），说明触发器根本没在从库执行，不是延迟问题
真正麻烦的是那些“看起来一致但逻辑错位”的情况：比如主库触发器按ORDER BY created_at LIMIT 1选一行更新，从库因排序字段值相同导致选中不同行——这种差异ROW模式也救不了，得靠业务层加唯一约束或改用确定性逻辑。
