先说结论：**ROW 格式能从根本上避免主从不一致，核心原因在于它记录的是行级变更结果，而不是原始 SQL 语句**。这一点决定了它在很多关键场景下的可靠性远高于 STATEMENT。 ## ROW 格式如何从根本上避免主从数据不一致？底层原理详解 STATEMENT 模式直接记录原始 SQL 语句，比如 `UPDATE users SET status = 1 WHERE created_at < NOW()`。主库执行时，`NOW()` 使用它自己的系统时间，而从库重放时，使用的是从库的系统时间。哪怕只差几秒，WHERE 条件匹配的行就可能完全不同。类似的还有 `UUID()`、`USER()`、`LAST_INSERT_ID()` 这类函数，每次执行结果都带有执行上下文，在从库重放时自然不可控。 ROW 模式完全不依赖这些函数。它只记录“哪几行被改了、旧值是什么、新值是什么”。主库写入 binlog 的是具体行的主键和列值快照，从库按图索骥，直接更新，彻底绕过了执行环境带来的差异。 - 非确定性函数（如 `NOW()`、`UUID()`）在 STATEMENT 模式下必然导致主从偏差，这是最为典型的问题。 - 索引选择差异同样会引发问题。举个例子：主库走 `idx_age` 执行 `DELETE ... WHERE age > 25`，但从库因为统计信息陈旧，可能改用 `idx_updated_at`，实际删除的行完全不同。 - 事务内多语句如果存在顺序依赖（比如先 INSERT，再用 `LAST_INSERT_ID()` 做 UPDATE），STATEMENT 无法保证从库的执行顺序与主库完全一致。 ## MySQL 8.0 中，STATEMENT 格式已被事实弃用 MySQL 8.0 启动时，如果你在 `my.cnf` 里没有显式配置 `binlog_format`，默认值就是 **ROW**，而不是 MIXED。更直观的是，很多场景下 MySQL 会主动拒绝记录 STATEMENT 日志： - 执行 `INSERT ... SELECT` 带子查询时，直接报错 `Statement is not safe to log in statement format`。这不是 bug，是 MySQL 主动拦截，因为它知道这里存在风险。 - 启用 GTID 后，某些 STATEMENT 语句会被强制降级为 ROW，而且不给你任何提示。复制链路一旦混用格式，从库直接报错 `The sla ve is running with binlog_format = STATEMENT, but the master sent a ROW event`。 - 如果 `sql_mode` 设置不一致（比如主库开了 `STRICT_TRANS_TABLES` 而从库没开），STATEMENT 语句在从库可能因为校验失败导致复制中断。 简而言之，MySQL 8.0 的态度很清楚：ROW 是默认选项，也是唯一推荐的选择。 ## ROW 格式不仅保障安全，更是现代数据链路的基础 你用的 Canal、Maxwell、Flink CDC、ShardingSphere 这些增量同步工具，它们全都靠解析 ROW 格式的 binlog 内容来工作。STATEMENT 日志里没有行级变更细节，这类工具要么无法工作，要么需要额外引入 SQL 解析器——精度和性能都会大打折扣。 审计回滚、误操作恢复也离不开 ROW： - 用 `mysqlbinlog --base64-output=DECODE-ROWS -v` 可以直接看到被删除的每一行原始数据。 - 配合 `binlog_row_image = FULL`（默认值），即使 UPDATE 只改了一个字段，也能还原出整行旧值，精准闪回不再困难。 - 并行复制（`sla ve_parallel_type = LOGICAL_CLOCK`）必须基于 ROW 事件才能正确分发事务。 ## 不必被“日志变大”吓退，先了解实际代价 确实，全表 UPDATE 会生成大量 ROW 事件。但现实是，这种高危操作本身就不应该频繁发生。真正需要关注的是：磁盘增长有没有评估？压缩功能开了没有？ - MySQL 8.0.20 及以上版本支持 `binlog_transaction_compression = ON`，对 ROW 日志的压缩率通常能达到 50%~70%。需要注意，`mysqlbinlog` 也需要 8.0.20+ 版本才能解压。 - 批量操作建议拆成小事务（比如每次 1000 行），既能降低单次 binlog 体积，也能减少锁持有时间和复制延迟。 - 如果业务真有高频的全表更新，优先考虑优化 SQL 逻辑或添加覆盖索引，而不是退回 STATEMENT——那是在用数据一致性换磁盘空间，不值得。 最后提醒一句：`binlog_format` 虽然是全局变量，但它的生效依赖配置文件加重启。仅仅执行 `SET GLOBAL binlog_format = 'ROW'` 只能临时生效，mysqld 重启后会立刻回退。生产环境务必写进 `my.cnf` 的 `[mysqld]` 段，并确认主从配置严格一致。