新项目或强一致场景必须选ROW；STATEMENT因NOW()、UUID()等非确定性函数必然导致主从不一致，生产环境基本不可用；MIXED依赖MySQL自动判断，存在识别盲区和误判风险，不是兜底而是陷阱。
直接结论：新项目或对一致性有要求的系统，无条件选 ROW；仅当明确知道所有 SQL 都是确定性的、且资源极度受限（如老报表库只读从库），才考虑 STATEMENT；MIXED 不是兜底方案，而是过渡陷阱。
为什么 STATEMENT 在生产环境基本不能用
它记录的是原始 SQL，靠从库重放来同步，但很多常见写法在主从上执行结果天然不同：
-
UPDATE t SET updated_at = NOW()：主库执行时取当前时间，从库重放时取的是它自己的当前时间，差几秒就可能引发状态错乱 -
DELETE FROM logs LIMIT 10：没ORDER BY，InnoDB 行物理顺序不保证，主从删的可能是完全不同的 10 行 -
INSERT INTO audit VALUES (UUID())：主库生成一个 UUID，从库重放时再生成一个新 UUID，两边数据彻底不一致 - 触发器、存储过程、自定义函数（未声明
DETERMINISTIC）：执行上下文差异导致逻辑分叉
这些不是“小概率问题”，而是只要出现一次，就会造成主从数据永久性偏差——你没法靠“监控延迟”发现，只能靠全量校验，成本极高。
ROW 模式到底记什么、有什么代价
ROW 不记 SQL，只记「哪一行、哪个字段、从什么值变成什么值」。比如一条 UPDATE user SET status = 'paid' WHERE id = 123，binlog 里实际写入的是：
Write_rows_log_event: table `db`.`user`, row #1 → before: {id:123, status:'pending'}, after: {id:123, status:'paid'}
它的代价集中在三类场景：
-
ALTER TABLE：MySQL 内部会转为逐行重建，大表操作会瞬间打爆磁盘 IO 和网络带宽，binlog文件体积可能暴涨数十倍 -
UPDATE ... WHERE匹配大量行：比如更新百万用户积分，ROW会写百万条变更事件，而STATEMENT只写一行 SQL - 高频率小更新（如计数器
UPDATE stats SET cnt = cnt + 1 WHERE k = 'req_total'）：每条都记完整前后镜像，日志膨胀比预期更明显
但这些是可评估、可规避的——DDL 提前做、批量操作拆分、高频计数改用 Redis 等。一致性一旦出问题，修复成本远高于日志开销。
别信 MIXED，它不会自动帮你兜底
MIXED 看似聪明：日常语句走 STATEMENT，遇到 NOW() 就切 ROW。但问题在于：
- MySQL 对“非确定性”的识别不完整。比如子查询里用了
RAND()，但外层没显式暴露，它可能仍按STATEMENT记录 - UDF（用户自定义函数）没加
DETERMINISTIC声明，MySQL 就不敢赌，强制切ROW，某天批量导入突然让binlog翻 10 倍 - 你无法预测哪条语句会被切——线上查
SHOW BINLOG EVENTS才能确认，排查“为什么这条没同步”反而更耗时
它不是智能降级，而是把判断权交给 MySQL 内部启发式规则。真实业务里，不如把不确定性从源头清除（比如 UUID() 移到应用层生成），然后坚定用 ROW。
怎么验证当前生效的格式和实际行为
别只看配置，要查运行时真实记录方式：
- 查当前设置：
SELECT @@binlog_format;—— 注意这是会话级变量，得看全局：SELECT @@global.binlog_format; - 查最近 binlog 事件类型：
SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 5;—— 看Event_type是Query_log_event（statement）还是Write_rows_log_event（row） - 改配置后必须
STOP SLAVE; START SLAVE;才能让从库重新加载格式，否则旧复制线程继续用旧模式
最容易被忽略的一点：ROW 模式下，SELECT 不进 binlog，但 SELECT ... INTO OUTFILE 或 CREATE TABLE AS SELECT 这类隐式写操作会记录——它们被当作 DML 处理，可能意外触发全表扫描写入，上线前务必在测试环境跑一遍真实流量回放。
