MySQL 的二进制日志（binlog）是数据库最重要的日志之一，它记录了所有对数据库执行更改的操作（不包括 SELECT、SHOW 等只读操作）。binlog 在数据恢复、主从复制、审计等场景中扮演着核心角色。而 binlog 的格式直接决定了日志记录的内容、体积以及对主从复制一致性的影响。MySQL 提供了三种 binlog 格式：STATEMENT、ROW 和 MIXED。理解它们的区别以及在不同场景下的选择，是 MySQL 面试中的高频考点，也是生产环境调优的必备知识。
一、为什么 binlog 格式如此重要？
在深入三种格式之前，先明确 binlog 的核心作用：
- 主从复制：从库通过重放主库的 binlog 来保持数据同步。
- 数据恢复：利用全量备份 + binlog 可以实现基于时间点的恢复（PITR）。
- 审计与变更追踪：通过分析 binlog 可以了解数据变更历史。
不同的 binlog 格式，会直接影响复制的可靠性、日志文件的大小、以及某些函数（如 NOW()、RAND()、UUID()）在从库上重放时是否会产生不一致。因此，选择哪种格式，本质上是在一致性、性能、磁盘空间三者之间做权衡。
二、三种 binlog 格式详解
1. STATEMENT 格式
定义：记录的是 SQL 语句本身。例如执行 UPDATE users SET age = age + 1 WHERE id = 10;，binlog 中记录的就是这条 SQL 文本。
优点：
- 日志文件小，节省磁盘 I/O 和网络带宽。
- 对于批量更新（如
UPDATE影响多行），只记录一条 SQL，日志量远小于 ROW 格式。 - 可读性强，便于人工审查。
缺点：
- 某些函数会导致主从不一致。例如
NOW()、CURRENT_TIMESTAMP、RAND()、UUID()、USER()等，在主库和从库上执行可能得到不同结果。 - 对于
INSERT ... SELECT、UPDATE ... LIMIT等不确定的语句，复制可能出错。 - 从库重放时需要重新执行 SQL，可能比 ROW 格式更消耗 CPU（尤其是复杂查询）。
典型不一致场景：
-- 主库执行
UPDATE t SET c = NOW() WHERE id = 1;
-- 从库重放时，NOW() 返回的是重放时刻的时间，而非主库执行时刻
2. ROW 格式
定义：记录的是每一行数据的实际变更。例如上面的 UPDATE 影响 3 行，binlog 中会记录 3 条行变更记录（前镜像 + 后镜像）。
优点：
- 主从数据强一致。因为记录的是行的最终值，不依赖 SQL 执行环境，任何函数、触发器、存储过程的结果都会被正确复制。
- 复制更可靠，几乎不会出现因语句不确定性导致的主从不一致。
- 对于复杂语句，从库重放时只需应用行变更，效率可能更高。
缺点：
- 日志文件大。批量更新 10 万行，就会产生 10 万条行记录，磁盘和网络开销显著。
- 可读性差，需要借助
mysqlbinlog -v等工具才能解析。 - 对于
DELETE、UPDATE全表操作，日志膨胀严重。
适用场景：对数据一致性要求极高的场景，如金融、订单系统。
3. MIXED 格式
定义：MySQL 会根据具体执行的 SQL 语句，自动在 STATEMENT 和 ROW 之间切换。默认使用 STATEMENT，遇到可能引起不一致的语句（如包含 NOW()、RAND()、UUID() 等）时自动切换为 ROW。
优点：
- 兼顾了日志体积和一致性。大部分普通语句用 STATEMENT，节省空间；不确定语句用 ROW，保证一致。
- 是 MySQL 5.1 之后推荐的过渡方案。
缺点：
- 仍然存在一些边界情况可能判断失误（虽然很少）。
- 格式不统一，排查问题时需要同时理解两种格式。
三、三种格式对比总结
| 对比维度 | STATEMENT | ROW | MIXED |
|---|---|---|---|
| 记录内容 | SQL 语句 | 行变更前后镜像 | 自动选择 |
| 日志体积 | 小 | 大 | 中等 |
| 主从一致性 | 弱（函数、不确定性语句） | 强 | 较强 |
| 可读性 | 好 | 差 | 中等 |
| 从库重放开销 | 可能高（重新执行 SQL） | 低（直接应用行） | 中等 |
| 适用场景 | 简单 SQL、日志敏感 | 高一致性要求 | 通用场景 |
四、主从复制中如何选择？
1. 默认与推荐
- MySQL 5.7.7 之前，默认
binlog_format = STATEMENT。 - MySQL 5.7.7 及之后，默认
binlog_format = ROW。 - MySQL 8.0 继续默认 ROW。
生产环境强烈推荐使用 ROW 格式，原因如下：
- 数据一致性是主从复制的第一要务。ROW 格式从根本上避免了函数、触发器、存储过程导致的不一致。
- 现代硬件磁盘和网络带宽已不再是瓶颈，ROW 格式的额外开销可以接受。
- 许多新特性（如 GTID 复制、组复制、InnoDB Cluster）都强烈依赖 ROW 格式。
2. 何时考虑 STATEMENT 或 MIXED？
- 磁盘空间极度紧张，且业务 SQL 简单、无不确定性函数，可以考虑 STATEMENT。
- 需要人工审计 SQL，STATEMENT 可读性更好。
- 历史遗留系统，暂时无法切换，可继续使用 MIXED 作为过渡。
但需要注意：在 ROW 格式下，如果执行了 UPDATE 或 DELETE 而没有走索引，会导致全表扫描并记录大量行变更，可能引发主从延迟。因此，ROW 格式下更要关注 SQL 索引优化。
3. 动态切换与注意事项
可以在线修改 binlog 格式：
SET GLOBAL binlog_format = 'ROW';
但已连接的会话不会立即生效，需要重新连接。另外，修改格式后，binlog 中会混合两种格式，从库需要能正确解析。建议在业务低峰期操作，并确保所有从库版本支持。
五、面试常见追问
-
ROW 格式下，
UPDATE没有索引会怎样？
会记录所有被扫描行的变更，即使这些行最终没有被更新（因为 MySQL 需要先读取再判断）。这会导致日志暴增和主从延迟。 -
STATEMENT 格式下，哪些函数会导致不一致？
非确定性函数：NOW()、SYSDATE()、RAND()、UUID()、USER()、CURRENT_USER()、LOAD_FILE()等。 -
MIXED 格式如何判断何时用 ROW？
MySQL 内部维护一个“不确定性”判断逻辑，遇到包含上述函数的语句、或者使用了LIMIT的 UPDATE/DELETE、或者使用了系统变量等，会自动切换为 ROW。 -
binlog_format 是会话级还是全局级？
既是全局也是会话级。全局修改后，新会话生效；当前会话可以用SET SESSION binlog_format = ...临时修改，但需要 SUPER 权限。
六、总结
MySQL binlog 的三种格式各有优劣：STATEMENT 节省空间但一致性弱，ROW 一致性强但日志大，MIXED 试图折中。在主从复制场景中，ROW 格式是当前生产环境的绝对主流和推荐选择，尤其对于金融、电商等对数据一致性要求苛刻的业务。理解三种格式的区别，不仅能帮助你在面试中脱颖而出，更能让你在实际运维中做出正确的架构决策。记住：一致性优先，空间换安全，是数据库复制领域不变的真理。
未经允许不得转载：任鹏个人博客 » MySQL binlog 三种格式的区别与主从复制中的选择
