调整 binlog_format 为 ROW 模式本身通常会增加日志体积，但配合设置 binlog_row_image=MINIMAL 可显著减少行模式下的冗余数据同步流量。适用场景为对主从数据一致性要求高且希望优化 ROW 模式开销的生产环境，风险边界在于 MySQL 5.6 及以上版本才支持 MINIMAL 参数。

命令速用版

临时生效命令（重启失效）：

SET GLOBAL binlog_format = 'ROW';
SET GLOBAL binlog_row_image = 'MINIMAL';

永久生效配置（my.cnf）：

[mysqld]
binlog_format = ROW
binlog_row_image = MINIMAL

为什么会这样

ROW 模式记录的是行变更前后的镜像，而 binlog_row_image 参数决定记录多少列数据。

默认 binlog_row_image=FULL 会记录整行所有字段的前后镜像，导致宽表更新时日志体积暴增。改为 MINIMAL 后，只记录 WHERE 条件列（前镜像）和变更列（后镜像），大幅减少日志量，尤其对宽表 UPDATE 场景效果明显。但需注意，ROW 格式本身比 STATEMENT 格式日志量大，MINIMAL 是在 ROW 格式基础上的优化，并非比 STATEMENT 更小。

分步处理

1. 确认版本与现状：执行 SELECT VERSION(); 确认 MySQL 版本支持 MINIMAL 参数，执行 SHOW VARIABLES LIKE 'binlog_format'; 查看当前格式。

2. 修改主库配置：先在主库执行 SET GLOBAL binlog_format = 'ROW'; 和 SET GLOBAL binlog_row_image = 'MINIMAL'; 临时生效。

3. 重启应用连接：已有连接仍沿用旧格式，必须重启所有应用连接池或等待旧连接自然断开，确保新连接使用新格式。

4. 固化配置：将 binlog_format = ROW 和 binlog_row_image = MINIMAL 写入主库配置文件 [mysqld] 段，防止重启失效。

5. 检查从库：从库无需修改 binlog_format（它只读不写），但需确认 relay_log_format 是默认值，观察 SHOW SLAVE STATUS\G 确保同步正常。

怎么验证是否生效

在主库执行 SHOW VARIABLES LIKE 'binlog_format'; 和 SHOW VARIABLES LIKE 'binlog_row_image';，返回值应分别为 ROW 和 MINIMAL。

观察 binlog 文件大小增长趋势，对比调整前后相同业务量下的文件增长速率。

在从库执行 SHOW SLAVE STATUS\G，确认 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes，且 Seconds_Behind_Master 无异常突增。

常见坑

1. 旧连接复用：ORM 框架可能缓存连接并复用旧会话，导致混合日志格式，引发从库解析失败，必须重启应用。

2. 版本限制：binlog_row_image = MINIMAL 需要 MySQL 5.6 及以上版本，低版本不支持该参数。

3. 流量误解：ROW 格式本身比 STATEMENT 格式日志量大，MINIMAL 仅减少 ROW 格式内的冗余，不能期望比 STATEMENT 更省流量。

4. 数据一致性：除非 100% 确保所有写操作都是确定性 SQL，否则不要为了省流量回退到 STATEMENT 格式。

常见问题

ROW 模式比 STATEMENT 模式更省流量吗？

不是，ROW 模式通常日志体积更大，STATEMENT 模式日志体积极小但存在一致性风险。

修改 binlog_format 需要重启 MySQL 服务吗？

SET GLOBAL 命令不需要重启服务但重启失效，写入配置文件需要重启服务或等待新连接生效。

从库需要设置 binlog_row_image 吗？

不需要，从库只读不写，binlog_format 和 binlog_row_image 只需在主库设置。

参考来源

mysql 如何实现高性能的主从复制_调整 binlog 格式与同步策略

mysql 主从复制如何调优性能_mysql 优化方案解析

MySQL Binlog 三种格式详解 + SpringCloud 微服务选型方案

mysql 如何配置 binlog 格式与清理_调整 sync_binlog 参数

降低 MySQL Binlog 存储占用的方法