主从数据不一致很大概率源于binlog_format配置不当，尤其STATEMENT模式下NOW()、UUID()等非确定性函数及子查询、自增主键、触发器等导致从库执行结果不同；MIXED模式存在判断盲区，推荐使用ROW+FULL组合以确保完整行镜像和准确校验。
主从数据不一致，很大概率是 binlog_format 配置不当导致的，而不是网络或硬件问题。 特别是在使用 STATEMENT 格式时，很多看似正常的 SQL 会在从库执行出错或结果不同——这不是 bug，是设计如此。
为什么 STATEMENT 格式容易引发不一致
它只记录原始 SQL 语句，不记录实际变更的数据行。从库重放时，依赖的是语句执行时的上下文环境，而这个环境在主从之间可能不同：
-
NOW()、UUID()、USER()等函数在从库执行时返回值不同 - 基于子查询或临时表的 UPDATE/DELETE，主库执行一次，从库可能因执行顺序或索引选择不同而影响范围
- 自增主键冲突：主库 INSERT 生成 ID=100，从库如果已有该 ID 行（比如误写），会报错并中断复制
- 存储过程、触发器、用户变量（
@var）行为不可预测，STATEMENT 下无法保证主从语义一致
MIXED 不是万能解药，得看 MySQL 版本和配置
MySQL 声称会“自动判断是否安全”，但这个判断有盲区：
- 5.6 及更早版本对非确定性函数识别能力弱，常漏判
- 即使启用了
MIXED，若binlog_row_image是MINIMAL（默认值），UPDATE/DELETE 在 ROW 模式下也只记录被改字段，丢失完整行镜像，导致pt-table-checksum校验失败或恢复困难 - 某些 DDL + DML 混合操作（如 ALTER TABLE 后紧跟 INSERT）仍可能 fallback 到 STATEMENT 并出问题
排查时优先确认 binlog_format 和 binlog_row_image
别只查 SHOW VARIABLES LIKE 'binlog_format'，这两项必须一起看：
- 在主库执行：
SELECT @@binlog_format, @@binlog_row_image; - 理想组合是：
ROW+FULL—— 这样每条变更都记录完整前镜像和后镜像，mysqlbinlog可解析出原始数据，pt-table-checksum能准确比对，误操作也能回滚 - 如果看到
STATEMENT或binlog_row_image=MINIMAL，立刻检查应用是否真依赖了非确定性函数；若无强依赖，直接改配置并重启 mysqld - 注意：修改后新 binlog 生效，旧 binlog 仍按原格式记录，所以切换后要观察至少一个完整业务周期
真正麻烦的不是发现不一致，而是发现时已经过了 binlog 有效期（expire_logs_days 设得太小），或者 relay log 已损坏。这时候 ROW + FULL 就不只是“推荐”，而是唯一能靠日志兜底的底线配置。
