statement模式因记录非确定性sql易致主从不一致；row模式因记录行级变更导致日志膨胀和延迟；mixed按规则自动切换但非万能；主从一致性需综合binlog_format、gtid、sql_mode等多因素保障。
binlog_format=STATEMENT 导致主从数据不一致的典型场景
STATEMENT 模式记录的是原始 SQL 语句，只要语句在从库执行结果和主库不同，就会出问题。比如用 NOW()、UUID()、USER()、@@server_id 这类非确定性函数，或者依赖自增 ID 的 INSERT … select，在从库重放时可能生成不同值或违反唯一约束。
常见错误现象：Duplicate entry 'X' for key 'PRIMARY' 或从库查不到某条记录但主库有。
- 避免在业务 SQL 中使用非确定性函数；若必须用，改写为常量或提前计算好传入
- 带
ORDER BY RAND()的 LIMIT 查询，在从库排序结果可能不同，直接导致数据错位 - 触发器里修改其他表，STATEMENT 不记录触发器内部操作，从库不会执行
ROW 模式下 binlog 体积暴涨和延迟升高的原因
ROW 模式记录每一行变更的完整前像（before image）和后像（after image），尤其对 UPDATE/delete 影响大。一条更新百万行的语句，在 STATEMENT 下只记一行 SQL，而在 ROW 下可能生成上百万条变更记录。
性能影响明显：磁盘 IO 增加、网络传输变慢、从库 SQL 线程解析压力大，容易出现 Seconds_Behind_Master 持续上涨。
- 大事务是 ROW 模式的天敌——拆分批量操作，单次 UPDATE 控制在 1k 行以内
- 确认是否真需要全字段日志：
binlog_row_image=MINIMAL可只记录被修改列（mysql 5.6+），但要求主从版本一致且表有主键或唯一键 - 注意
innodb_flush_log_at_trx_commit=1和sync_binlog=1组合会进一步拖慢写入，高并发写场景可酌情调松
MIXED 模式不是“自动兜底”，它按规则降级而非智能判断
MIXED 不是 STATEMENT + ROW 的混合输出，而是 MySQL 内部按预设规则决定某条语句用哪种格式记录。比如遇到 UUID() 就自动切到 ROW，遇到简单 INSERT 就用 STATEMENT。但它不会分析你的业务逻辑是否安全，也不会感知存储过程里有没有非确定性操作。
容易踩的坑：SET sql_log_bin=0 后执行的语句不记 binlog，MIXED 也无能为力；而某些函数（如 SLEEP()）在 MIXED 下仍走 STATEMENT，导致从库秒级延迟不可控。
- 不要以为开了 MIXED 就高枕无忧——它无法覆盖所有非确定性场景，特别是自定义函数或 UDF
- 升级 MySQL 版本后，MIXED 的降级规则可能变化（如 5.7 对
CONVERT_TZ()的处理就和 5.6 不同） - 想验证实际用了哪种格式？查
SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 10，看 Event_type 是Query_log_event（STATEMENT）还是Write_rows_log_event（ROW）
主从一致性校验不能只靠 binlog_format 设置
即使你选了 ROW，也不能保证主从绝对一致。比如从库 crash 后重启，如果 relay_log_recovery=OFF，可能丢掉部分中继日志；又或者主库开启 slave_parallel_workers > 0 但没配 slave_preserve_commit_order=ON，并行回放可能导致事务顺序错乱。
真正影响一致性的，是 binlog_format、复制过滤规则、GTID 开关状态、甚至从库的 SQL_MODE 是否和主库严格一致。
- 检查
SELECT @@sql_mode在主从是否完全相同，尤其注意STRICT_TRANS_tableS缺失会导致截断警告变成静默成功 - 用
pt-table-checksum定期校验表内容，别只盯着Seconds_Behind_Master=0 - ROW 模式下，从库的
binlog_format参数其实不影响复制，但它会影响从库自己产生的 binlog——如果你做级联复制，这个值就关键了
事情说清了就结束。