binlog_row_image=minimal是row模式下唯一真正有效的减流手段，它仅记录where条件列和实际修改列，使binlog体积降至full模式的30%–70%，但要求表有主键或唯一非空索引，否则自动降级为full。
ROW 格式本身不减少流量，但配合 binlog_row_image 可显著压缩日志体积——这是唯一真正有效的“减流”手段。
为什么 STATEMENT/MIXED 不能安全用于减流
STATEMENT 模式看似日志小，但遇到 NOW()、UUID()、自增主键、触发器等非确定性操作时，从库重放结果可能和主库不一致。MIXED 模式虽自动降级，但切换逻辑黑盒，故障时难以定位。生产环境已基本弃用这两种模式来“省流量”，因为数据错位的代价远高于带宽成本。
- 常见错误现象：
Slave_SQL_Running: No+Last_SQL_Errno: 1062（主键冲突），常源于 STATEMENT 模式下从库生成了不同UUID() - 使用场景：仅适用于极老系统、无函数/存储过程、且能接受偶发不一致的离线报表库
- 性能影响：STATEMENT 写入快，但 SQL Thread 执行压力大；ROW 写入慢，但 SQL Thread 执行轻量——流量瓶颈通常在 I/O 和网络，而非从库 CPU
binlog_row_image=MINIMAL 是 ROW 模式下的核心减流开关
默认 binlog_row_image=FULL 会记录整行变更前后的所有字段，哪怕只改一个 status 字段，也把整条记录都记下来。设为 MINIMAL 后，只记录 WHERE 条件涉及的字段（旧值）和实际被修改的字段（新值），对批量更新尤其有效。
- 实操建议：MySQL 5.6+ 必须搭配
binlog_format=ROW使用；执行SET GLOBAL binlog_row_image = 'MINIMAL'后，需重启应用连接池（同binlog_format切换逻辑） - 注意点：
MINIMAL要求主库开启innodb_read_only_off（即非只读），否则 UPDATE/DELETE 可能因找不到旧值而失败 - 验证方式：用
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000001 | grep -A 5 "### UPDATE"对比前后日志行数
别碰 sync_binlog=0，它不减流量只增风险
sync_binlog=0 是让 OS 决定何时刷盘，看起来写得快、日志落盘延迟高，但会导致主库崩溃后 binlog 丢失，从库永远追不齐——这不是“减流量”，是制造同步断裂。真正影响流量的是日志内容本身，不是刷盘频率。
- 容易踩的坑：有人误以为调大
sync_binlog（如设为 100）能“攒日志一起发”，其实它只控制刷盘批次，不影响网络传输粒度；binlog 还是按事务逐条发送给从库 I/O Thread - 正确做法：保持
sync_binlog=1，靠binlog_row_image=MINIMAL和合理max_binlog_size控制单次传输量 - 兼容性提醒：MySQL 8.0.23+ 支持
binlog_row_image=NOBLOB，若表含大字段（TEXT/BLOB）且不常更新，可进一步压缩，但需确认业务是否依赖 BLOB 字段的精确同步
真正影响流量的从来不是格式选择本身，而是你有没有关掉冗余字段记录。很多团队花时间纠结 STATEMENT vs ROW，却漏掉 binlog_row_image 这个开关——它才是 ROW 模式下最该调、也最容易被忽略的减流杠杆。
