statement格式不推荐因其记录原始sql，含now()、uuid()等非确定性函数时主从执行结果不一致，且无法支持误删回滚；row格式记录行级变更前后完整值，可精准恢复，是唯一可靠选择。
STATEMENT格式为什么现在基本不推荐用
它记录的是原始SQL语句，比如UPDATE users SET status = 1 WHERE id IN (SELECT id FROM temp_ids)，binlog里就存这整条语句。问题在于：只要语句里带NOW()、RAND()、UUID()、USER()、LIMIT或子查询依赖临时表，回放时结果就可能和原操作不一致。更麻烦的是，你根本看不到哪几行被改了——误删后想反向还原？没戏。线上环境一旦遇到主从数据不一致，排查起来非常被动。
ROW格式是误删/误更新恢复的唯一可靠选择
它记录每一行变更前后的完整字段值（即Before image和After image），比如DELETE会记下被删行所有列的原始值；UPDATE则同时保留修改前和修改后的整行数据。这意味着你可以从mysqlbinlog输出中直接提取出“该INSERT回去”的原始记录。
- 必须开启
binlog_row_image=FULL（默认值），否则可能只记部分字段 - 单次大事务影响百万行时，binlog体积可能暴涨数倍，磁盘和网络压力明显上升
- DDL语句（如
ALTER TABLE）仍以语句形式记录，不走行镜像逻辑 - 解析时要用
mysqlbinlog --base64-output=DECODE-ROWS -v才看得清具体值
MIXED格式不是“自动智能切换”，而是有明确触发规则
MySQL不会凭感觉决定用哪种格式，它有一套硬编码的判断逻辑：遇到UUID()、SYSDATE()、存储过程、触发器、不确定子查询等，就强制切到ROW；其余多数DML走STATEMENT。但这个“多数”并不包括你写的业务SQL是否真安全——比如一个看似简单的UPDATE若隐含函数调用，MIXED也可能在主库用STATEMENT记录，从库回放就偏移。
- 配置为
MIXED后，无法保证所有变更都可逆恢复 - 日志大小介于STATEMENT和ROW之间，但调试复杂度反而更高——你得先确认某条日志到底是哪种格式生成的
- 运行时执行
SET SESSION binlog_format = ROW可临时覆盖，但仅对当前会话生效
选型真正取决于你要解决什么问题
如果目标是“能精准回滚误操作”，那只有ROW格式满足条件；如果只是做主从同步且业务SQL极其规范（无任何非确定性函数、无跨库引用、无复杂子查询），STATEMENT理论上可行，但风险不可控；MIXED看起来折中，实则把不确定性交给了MySQL内部逻辑——而你在恢复数据时，最不能依赖的就是“不确定性”。
最容易被忽略的一点是：binlog_format是会话级变量，即使全局设为ROW，某些ORM或中间件连接池可能在建连时显式执行SET SESSION binlog_format = STATEMENT，导致关键操作悄悄退化。查恢复线索前，务必确认对应事务实际写入的日志格式。
