statement 模式在生产环境基本不能用，因其遇到 now()、uuid()、rand()、user()、@variable 等非确定性元素时主从结果必然不同，导致数据不一致；而 row 模式只记录表、行、字段的前后镜像，通过 mysqlbinlog --base64-output=decode-rows --verbose 可解析，能 100% 保证主从一致。
STATEMENT 模式为什么在生产环境基本不能用
它不是“偶尔出错”，而是只要 SQL 里出现 NOW()、UUID()、RAND()、USER()、@variable 这类非确定性元素，主从执行结果就必然不同。
常见错误现象包括：
-
UPDATE user SET updated_at = NOW()：主库写入时间戳是 14:02:03，等 binlog 同步到从库再执行，从库系统时间可能是 14:02:06，字段值直接偏差 3 秒 -
DELETE FROM logs LIMIT 10：没ORDER BY，InnoDB 行物理顺序不保证，主从删的极可能是完全不同的 10 行 -
INSERT INTO audit VALUES (UUID())：主库生成一个 UUID，从库重放时再生成一个新 UUID，两边数据彻底不一致 - 含触发器或未声明
DETERMINISTIC的自定义函数：执行上下文差异导致逻辑分叉，且无法被监控发现
这些不是边缘 case——只要上线，就可能在某次部署、某个定时任务、某条报表 SQL 中触发。修复只能靠全量校验，成本远高于预防。
ROW 模式到底记什么、怎么看懂它
ROW 不记录 SQL，只记录「哪张表、哪几行、哪个字段、旧值是什么、新值是什么」。本质是数据变更快照流，所以能 100% 保证主从一致。
查看 ROW 日志必须加两个参数：mysqlbinlog --base64-output=decode-rows --verbose，否则看到的是加密的 base64 字符串。
实操注意点：
- 一条
UPDATE product SET price = 99 WHERE id IN (1,2,3)会生成 3 条独立事件（每行一条），不是 1 条语句 -
DDL（如ALTER TABLE）仍是明文，但DML默认加密——别误判为“日志不可读” - 无主键表在 ROW 模式下复制会严重延迟：MySQL 需全表扫描匹配条件行，无法走索引定位
MIXED 模式真能自动兜底？
MIXED 不是智能选择，而是 MySQL 根据内置规则表硬编码判断：遇到 UUID()、SYS_DATE()、存储过程、触发器、用户变量等，就切 ROW；其余走 STATEMENT。
但它完全不理解你的业务逻辑是否安全：
- 你写的
UPDATE t SET x = @a := @a + 1会被识别为含用户变量，强制切 ROW——哪怕你只是本地测试，根本没打算让从库执行它 - 某些自定义函数或新版本函数，MySQL 判定不准，仍可能走 STATEMENT 导致不一致
- 规则表不会随业务演进更新，你加了一个新函数，它不会自动识别
所以 MIXED 不是兜底方案，而是过渡陷阱：它让你误以为“有保障”，实际一致性风险仍在暗处。
新项目或强一致场景必须选 ROW
ROW 的代价是可评估、可规避的：
-
ALTER TABLE大表操作：提前在低峰期做，或用pt-online-schema-change - 批量 UPDATE 百万行：拆成 1k/批，配合
SLEEP控制节奏 - 高频小更新（如计数器）：改用 Redis 或汇总表，别压在主库上
而 STATEMENT 的风险是不可控的——你没法预判哪条 SQL 会在哪天、哪个从库上悄悄破坏一致性。线上数据库一旦出问题，修复成本永远高于日志开销。最常被忽略的一点是：MySQL 5.7+ 已默认禁用 STATEMENT，设为该模式时会输出警告 [Warning] Statement may not be safe to log in statement format，这不是提示，是明确拒绝背书。
