Binlog_row_image 是 MySQL 5.6.2+ 控制 ROW 格式 binlog 记录列范围的变量，默认 FULL（记录整行新旧值），MINIMAL 仅记变更列及主键/唯一键，NOBLOB 排除 BLOB/TEXT 列，三者显著影响日志体积与同步安全。
Binlog_Row_Image 是什么，为什么会影响日志体积
binlog_row_image 是 MySQL 5.6.2+ 引入的系统变量，控制 ROW 格式 binlog 中每条变更记录写入哪些列值。它不改变 binlog 格式（仍需 binlog_format = ROW），但直接决定每条 UPDATE 或 DELETE 事件在日志里“拍多少快照”——比如是否包含旧值、新值、还是只存变化列。
默认值是 FULL，即无论哪列改了，UPDATE 都记录整行旧值 + 整行新值；DELETE 记录整行旧值。这对主从一致性最安全，但日志体积可能翻倍甚至更多，尤其宽表高频更新时。
三种取值对日志体积的实际影响
必须明确：只有 binlog_format = ROW 时该变量才生效。常见取值及效果如下：
-
FULL：UPDATE 记录 before_image（整行旧值）和 after_image（整行新值）；DELETE 记录 before_image。日志最大，安全性最高。 -
MINIMAL：UPDATE 只记录被修改列的旧值 + 新值（以及主键或唯一键用于定位行）；DELETE 只记录主键/唯一键值。日志最小，但要求表必须有有效主键或唯一非空索引，否则会报错ER_NO_REFERENCED_ROW。 -
NOBLOB：介于两者之间——排除BLOB/TEXT类型列的旧/新值（只记录其长度或 NULL），其余同FULL。适合含大字段但又不敢用MINIMAL的场景。
注意：INSERT 不受 binlog_row_image 影响，永远只记录新值（after_image）。
如何安全切换到 MINIMAL 以压缩日志
直接设 SET GLOBAL binlog_row_image = 'MINIMAL' 很快，但容易出问题。关键检查点：
- 确认所有业务表都有显式定义的主键（
PRIMARY KEY）或唯一非空索引（UNIQUE NOT NULL）。用SELECT table_name, column_name FROM information_schema.key_column_usage WHERE constraint_name = 'PRIMARY' OR (constraint_name != 'PRIMARY' AND constraint_schema = DATABASE())快速筛查缺失主键的表。 - 避免在 DDL 过程中切换：如正在执行
ALTER TABLE ... ADD COLUMN，此时切MINIMAL可能导致从库应用失败，因为新增列未出现在旧 image 中。 - 主从兼容性：MySQL 5.6.2+ 支持该变量，但低版本从库无法识别
MINIMAL日志，会报错Unknown binlog row image type。务必保证主从版本一致或从库 ≥ 主库版本。 - 监控日志增长：切换后观察
SHOW MASTER STATUS中File_size增速，以及磁盘上mysql-bin.*文件体积变化趋势，别只看单次写入量。
常见误判和线上踩坑点
很多团队以为 “开了 MINIMAL 就能省一半空间”，结果发现日志没怎么变小，甚至同步延迟上升。原因往往藏在这几处：
- 表里大量
UPDATE t SET c=c+1 WHERE id=123类语句：即使只改一列，MINIMAL仍要记录主键（用于定位）+ 被改列的新旧值，而如果主键本身很长（比如 UUID），或表没有主键只能退化为FULL模式，体积节省有限。 - 使用
REPLACE INTO或INSERT ... ON DUPLICATE KEY UPDATE：这类语句底层转成 DELETE + INSERT，MINIMAL下 DELETE 只记主键，但 INSERT 仍记全量新值，总体未必压缩。 - 开启
binlog_row_image = MINIMAL后未重启复制线程：从库 SQL 线程缓存了旧格式事件，需执行STOP SLAVE; START SLAVE;才真正启用新规则。 - 误认为
NOBLOB总比FULL小：若表不含 BLOB/TEXT，NOBLOB和FULL完全等效；若有但更新极少涉及这些列，压缩收益也有限。
真正显著压缩 binlog 体积，往往得配合其他手段：删减冗余索引（减少主键/唯一键长度）、避免无意义的 UPDATE、定期 purging binlog（expire_logs_days），而不是只押注 binlog_row_image。
