根本原因是Binlog格式语义差异，尤其STATEMENT模式记录SQL文本而非实际变更行，导致NOW()、UUID()、RAND()、USER()、INSERT...SELECT无ORDER BY、@user_variable等依赖本地上下文的语句在从库重放时结果不同。
MySQL主从架构下SQL执行结果不一致，**根本原因常出在Binlog格式对语句重放的语义差异上**，尤其是STATEMENT模式——它记录的是原始SQL文本，而非实际变更的数据行。
STATEMENT模式下哪些SQL必然导致主从不一致
这类语句在主库执行时依赖本地上下文（如函数返回值、临时表、用户变量），从库回放时环境不同，结果自然不同：
-
NOW()、CURDATE()、SYSDATE()：主库执行时刻的时间戳，从库回放时可能已过去数秒甚至更久 -
UUID()、RAND()、USER()：每次调用返回不同值，从库无法复现主库当时的输出 -
INSERT ... SELECT未加ORDER BY：InnoDB无显式排序时行顺序不确定，从库插入顺序可能不同，影响AUTO_INCREMENT分配或触发器行为 - 依赖
@user_variable的语句：变量作用域不跨语句，从库SQL线程单条执行时变量状态丢失
ROW vs MIXED模式是否就绝对安全
不是。虽然ROW模式记录的是“哪几行被改了”，语义确定，但仍有边界情况：
-
MIXED模式下，MySQL自动降级为STATEMENT的语句（如含LOAD_FILE()、FOUND_ROWS()）仍会暴露上述风险 -
ROW模式无法解决主从sql_mode不一致问题：例如主库STRICT_TRANS_TABLES关闭，插入超长字符串被截断；从库开启该模式则直接报错中断同步 - 从库若开启
read_only=0且被误写，后续相同ROW事件可能因主键冲突、唯一索引冲突而跳过或报错，数据悄然脱节
如何快速确认当前Binlog格式及潜在风险
别猜，直接查主库配置和运行时状态：
- 查全局格式：
SELECT @@binlog_format;—— 返回值必须是ROW才相对可控 - 查会话级覆盖：
SELECT @@session.binlog_format;—— 某些应用连接后主动SET，会绕过全局设置 - 查是否禁用日志：
SELECT @@sql_log_bin;—— 若为OFF，任何写操作都不会进Binlog，从库永远收不到 - 检查关键函数使用：
SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 20;看EVENT_TYPE是否含Query_log_event（即STATEMENT）
真正难处理的不是格式本身，而是那些“看起来能跑通、实际已悄悄不一致”的场景——比如UPDATE t SET c = UUID() WHERE id = 1在STATEMENT下主库更新成一个UUID，从库重放时生成另一个，连错误都不会报。
