SQL binlog_row_image=MINIMAL 的 binlog 体积优化与兼容性

binlog_row_image=minimal 仅记录update中where条件列和被修改列，实测节省40%–70%空间（局部更新前提下），但insert/delete无影响；需row格式、mysql 5.7.10+或8.0才正确支持；下游cdc、校验工具等须适配，否则解析失败。

binlog_row_image=MINIMAL 到底省了多少空间

它只记录被修改列的旧值和新值，不存整行。比如 UPDATE users SET name='Alice' WHERE id=1，在 MINIMAL 模式下，binlog 里只存 id（用于定位）和 name（变更字段），其他字段如 email、created_at 完全不写入。

实测常见业务表（10–20 列，含 TEXT/BLOB）开启后 binlog 体积下降 40%–70%，但前提是 DML 以「局部更新」为主；如果大量 UPDATE 实际改了整行（比如 ORM 全量覆盖），节省效果会大幅缩水。

• 对 INSERT 和 DELETE 无影响——这两类操作在所有 binlog_row_image 模式下都记录完整行
• UPDATE 的节省程度取决于 WHERE 条件匹配行数 × 实际修改列数，不是看 SQL 写了几列
• BINLOG 格式必须是 ROW，MIXED 或 STATEMENT 下该参数无效

MySQL 5.6/5.7/8.0 对 MINIMAL 的兼容性差异

不是所有版本都真正支持语义一致的 MINIMAL。MySQL 5.6 初期实现有缺陷：主键列即使没被 UPDATE，也会被强制记入前镜像（before image），导致体积没降多少；5.7.10+ 和 8.0 才修复为「仅记录 WHERE 中实际用到的列 + 修改列」。

如果你用的是 Percona Server 或 mariadb，注意它们的实现逻辑可能不同——比如 MariaDB 直到 10.5 才完全对齐 MySQL 8.0 的行为。

• 检查当前生效值：select @@binlog_row_image;，别只看配置文件，运行时可能被动态改过
• 从库升级前务必验证：老版本从库解析不了新主库发来的 MINIMAL Event，会报错 Unknown binlog row image type
• GTID 复制下更敏感，因为 event 解析失败会导致 Retrieved_Gtid_Set 和 Executed_Gtid_Set 错位

为什么 pt-table-checksum 和某些 CDC 工具会出错

这些工具依赖 binlog 中的完整前镜像做数据比对或构造反向 SQL。MINIMAL 下缺失未修改字段，导致 checksum 计算结果不一致，或 CDC 解析器抛出 column not found in row image 类错误。

典型场景：flink CDC 连接 MySQL 8.0，默认启用 MINIMAL，但没配 scan.startup.mode=initial 或没关 include-transaction-details，就会在 snapshot 阶段卡住或丢数据。

• pt-table-checksum 要求 binlog_row_image=FULL，否则校验失效——这是硬限制，不是警告
• Flink / Debezium 等需显式配置 database.server.name + table.include.list，并确认 connector 版本 ≥ 对应 MySQL 版本的最低要求
• 审计类中间件（如 MyRocks、一些自研 binlog 解析服务）若没适配 MINIMAL，可能直接跳过 event 或解析成 NULL 字段

切换前必须验证的三个动作

别只改配置重启完事。线上环境切 MINIMAL 前，得确认下游链路真能消化它。

最常被跳过的其实是「触发一次真实 UPDATE 并查 binlog event 结构」——用 mysqlbinlog --base64-output=decode-rows -v 看输出，确认你关心的字段是否真的没出现在 ### UPDATE ... 下的 ### @1=... 行里。

• 在从库上执行 STOP SLAVE; SET GLOBAL binlog_row_image = 'MINIMAL'; START SLAVE; 测试复制是否中断（别在主库直接试）
• 用业务流量压测 10–15 分钟，观察 SHOW SLAVE STATUSG 的 Seconds_Behind_Master 是否突增——MINIMAL 本身不慢，但下游解析压力可能变大
• 检查监控项：Com_update、Bytes_received、Binlog_cache_use，三者趋势要同步变化，否则说明应用层或中间件还在发全量 UPDATE

真正麻烦的从来不是参数本身，而是你以为它只影响 binlog 大小，其实它悄悄改写了下游所有依赖 binlog 解析的系统的输入契约。