三种格式的差别
binlog 既要给复制用，也要给按时间点恢复用，记录方式直接影响可靠性。ROW 记录每一行被修改前后的镜像，重放结果确定，是 MySQL 8.0 的默认值；STATEMENT 记录原始 SQL，体积小但带不确定函数的语句在重放时可能得到不同结果；MIXED 默认按 STATEMENT 记录，遇到无法安全重放的情况自动切换成 ROW。
基本信息
| 适用平台 | MySQL 5.7 / 8.0、MariaDB |
|---|---|
| 查看方式 | SHOW VARIABLES LIKE 'binlog_format' |
| 8.0 默认 | ROW |
| 行镜像控制 | binlog_row_image 取 full（默认）、minimal、noblob |
| 修改前提 | 需要 SYSTEM_VARIABLES_ADMIN 或 SUPER 权限 |
| 生产建议 | 统一使用 ROW |
典型使用场景
- 搭建与校验从库：确认位点重放结果与主库完全一致
- 按时间点恢复（PITR）前核对二进制日志格式，评估重放可靠性
- CDC 数据同步：下游工具通常依赖 ROW 格式解析行级变化
- 误操作后回捞数据：从 binlog 里定位事件并构造反向语句
- 审计变更：需要知道每一行改前改后的具体值
查看与调整
查看与调整
-- 查看当前格式与行镜像级别
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_row_image';
-- 会话级临时覆盖（谨慎，且需足够权限）
SET SESSION binlog_format = 'ROW';
-- 全局调整（仅影响新会话）
SET GLOBAL binlog_format = 'ROW';
-- 查看当前正在写的二进制日志文件与位点
SHOW BINARY LOG STATUS; -- 8.0.22+，旧版本用 SHOW MASTER STATUS三种格式对比
| 格式 | 记录内容 | 可靠性 | 体积 |
|---|---|---|---|
| ROW | 每行修改前后的镜像 | 重放确定，PITR 可靠 | 较大，可用 minimal 缩减 |
| STATEMENT | 原始 SQL 文本 | 含不确定函数时结果可能不一致 | 小 |
| MIXED | 按语句安全自动切换 | 同一事务内可能两种格式混用 | 介于两者之间 |
| binlog_row_image=minimal | 仅记录变更列 | 体积小，但 before 镜像不完整 | 最小 |
GTID 复制下改变 binlog 格式不会改变 GTID 语义，但重放结果的确定性仍取决于格式本身：只要追求可靠恢复，结论都是一样的，统一用 ROW。
把格式从 STATEMENT 切到 ROW 只对新写入生效：切换前的历史 binlog 仍是旧格式，做 PITR 时不能假设全部事件都可靠重放。