binlog_row_image=minimal 通过仅记录变更列或新增行（不记未改字段及delete旧值），使binlog体积降至full模式的30%–70%，但需row格式、主键/唯一索引支持，否则降级为full；其回放需补全行，若索引缺失会加剧延迟；无法屏蔽敏感列，需应用层脱敏或mysql 8.0.23+新特性配合。
binlog_row_image=MINIMAL 为什么能让 binlog 变小
它只记录被修改的列（UPDATE）或新增的行（INSERT），DELETE 不记录旧值，UPDATE 也不记未改动的字段。相比 FULL 模式下每行都全量记录，体积通常能压到 30%–70%，尤其宽表+稀疏更新时效果明显。
- 必须配合
ROW格式使用，MIXED或STATEMENT下该参数无效 - 依赖表有主键或唯一非空索引，否则 UPDATE/DELETE 无法定位行，MySQL 会自动降级为 FULL 行记录（不报错但悄悄失效）
- 触发器、生成列、json 字段更新时行为特殊：比如 JSON_SET() 修改部分字段，MINIMAL 仍可能记录整个 JSON 列——因为 MySQL 当前无法精确识别 JSON 内部变更
回放慢？先确认是不是 MINIMAL 导致的解析开销
MINIMAL 本身不拖慢回放，但会让从库在应用事件时多一步「补全行」操作：UPDATE 需先查主键拿到完整旧行，再合并变更；DELETE 也要先查再删。这会放大索引缺失、主键查询慢、大字段（如 TEXT）带来的 I/O 压力。
- 检查从库
SHOW SLAVE STATUSG中的Seconds_Behind_Master是否集中在 UPDATE/DELETE 多的表上 - 用
mysqlbinlog --base64-output=DECODE-ROWS -v看具体事件，确认是否频繁出现### UPDATE INTO `t` WHERE @1=1 AND @2=... /* added by mysqlbinlog */这类带 WHERE 的补全逻辑 - 如果表没有有效二级索引支撑补全查询，回放延迟会指数级上升——这不是 MINIMAL 的锅，是表设计缺陷暴露了
跳过某些列不写入 binlog？MINIMAL 不行，得靠其他机制
binlog_row_image=MINIMAL 控制的是“改了才记”，不是“哪些列永远不记”。想彻底屏蔽敏感列（如密码哈希），不能靠它。
- MySQL 8.0.23+ 可用
binlog_row_value_options='PARTIAL_UPDATES=ON'+ 列级权限控制，但仅限 JSON 和 GIS 类型 - 通用方案是应用层脱敏：写入前把
password_hash替换成固定占位符，再让 binlog 记这个“假值” - 试图用
SET session binlog_row_image=MINIMAL动态切换对已开启事务无效，且容易引发主从不一致——这个变量必须在事务开始前设置
线上切 MINIMAL 要防的三个坑
直接改配置重启可能让从库同步中断，尤其老版本 MySQL 或用了 GTID 的集群。
- 5.7.20 之前版本，从库
binlog_row_image必须和主库严格一致，否则报错Slave SQL Thread retried transaction - GTID 模式下，主库切 MINIMAL 后产生的事件，从库若仍是 FULL，可能因行映射不匹配导致
Could not execute Write_rows_v1 Event on table - 备份工具（如 mydumper）依赖 binlog 行格式还原数据，切完 MINIMAL 后记得同步更新备份策略——有些工具解析 MINIMAL 事件仍有兼容问题
真正麻烦的从来不是参数开关本身，而是它把原本被 FULL 掩盖的表结构缺陷、索引缺失、应用写法问题全暴露出来了。