将 binlog_row_image 设为 minimal 是压缩 row 格式 binlog 体积最直接有效的方式，但需满足表有主键或唯一非空索引、新建连接或显式设置会话级参数、避免 set col=col 无变更赋值、binlog_format 必须为 row；须用 mysqlbinlog 解析事件验证是否仅记录主键和实际变更列，否则仍为 full；还需配合 max_binlog_size、binlog_rows_query_log_events、binlog_do_db 等参数协同优化，并在从库验证后观察复制延迟与日均 binlog 增长量。
把 binlog_row_image 设为 MINIMAL 是压缩 Row 格式 binlog 体积最直接有效的方式，但必须满足前提、验证生效、配合其他设置，否则可能白配。
确认前提条件是否全部满足
MINIMAL 模式不会自动生效，它依赖底层表结构和连接状态：
- 目标表必须有主键，或存在唯一且所有列都定义为 NOT NULL 的索引（缺一不可）
- 已建立的客户端连接仍使用旧会话值，需新建连接或显式执行
SET SESSION binlog_row_image = 'MINIMAL' - UPDATE 语句中避免写
SET col = col这类无实际变更的赋值，MySQL 会误判为“被修改”而记录该列 - binlog_format 必须是 ROW——该参数对 STATEMENT/MIXED 格式完全无效
验证是否真正起效，别只看文件大小
日志体积受事务合并、BLOB 字段、并发写入等干扰，单看 SHOW BINARY LOGS 容易误判。应直接 inspect event 内容：
- 用命令解析最新 binlog：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.0000xx | grep -A 15 "UPDATE.*your_table" - 观察输出中的
### WHERE和### SET行：仅出现主键列 + 真正被改的字段 → MINIMAL 生效；若所有@1=@2=… 全量列出 → 实际仍是 FULL - 若表无主键，WHERE 部分会变成全字段比对（
@1=@1 AND @2=@2...），此时 MINIMAL 自动降级，等效 FULL
搭配关键参数协同压缩
单靠 binlog_row_image 不足以发挥最大效果，需组合优化：
- 设
max_binlog_size = 128M（而非默认 1G）：更早轮转，配合expire_logs_days = 7控制总量 - 关闭冗余记录：
binlog_rows_query_log_events = OFF（不存原始 SQL，减体积且防敏感泄露） - 限制作用范围：
binlog_do_db = your_app_db或binlog_ignore_db = mysql,information_schema - 确保
binlog_checksum = CRC32（默认开启），提升校验效率，避免因校验失败重传放大 IO
安全切换与线上观察要点
生产环境调整需闭环验证：
- 先在从库或测试实例执行：
SET GLOBAL binlog_row_image = 'MINIMAL'; - 跑典型业务 UPDATE，立即用 mysqlbinlog 检查 event 结构
- 紧盯复制延迟、错误日志（重点搜
row definition mismatch或Could not execute） - 持续观察 24 小时内 binlog 日均增长量变化趋势，对比调整前后数据
