binlog_row_image 有 FULL、MINIMAL、NOBLOB 三种取值：FULL 记录所有列新旧值，体积最大但兼容性最好；MINIMAL 仅记录定位行的列和实际修改列，需主键或唯一非空索引，否则降级为 FULL；NOBLOB 跳过 BLOB/TEXT 列的新旧值（除非该列被修改且非 BLOB/TEXT）。
Binlog-Row-Image 有哪几种取值，各自影响什么
MySQL 的 binlog_row_image 控制 Row 格式 binlog 中每条变更记录写入哪些列的数据，默认是 FULL。它有三个合法值：FULL、MINIMAL、NOBLOB。
关键区别在于：是否只记录被真正修改的列（MINIMAL），以及是否跳过 BLOB/TEXT 类型字段（NOBLOB）。
-
FULL：记录所有列的旧值 + 所有列的新值（UPDATE/DELETE 时旧值全存，INSERT 无旧值）。日志体积最大，但支持闪回、精确审计、逻辑复制兼容性最好 -
MINIMAL：仅记录 WHERE 条件涉及的列（用于定位行）+ 实际被修改的列（新值）。不记录未改动列，也不记录非必要旧值。体积最小，但要求主键或唯一非空索引存在，否则降级为FULL -
NOBLOB：介于两者之间，记录所有列，但跳过BLOB和TEXT列的旧值和新值（除非该列本身被修改且类型非 BLOB/TEXT）
为什么设成 MINIMAL 后 binlog 还没变小
常见误解是只要 SET GLOBAL binlog_row_image = 'MINIMAL' 就能立刻减小日志体积——实际并非如此。生效需同时满足多个前提：
- 表必须有主键，或有唯一且所有列都定义为
NOT NULL的索引（否则 MySQL 无法唯一定位行，自动退化为FULL） - 客户端连接需在变量设置后新建，已存在的连接仍用旧 session 值（
binlog_row_image是会话级变量，但全局设置只影响新会话） - 确认生效：执行
SELECT @@session.binlog_row_image，不是@@global.binlog_row_image - UPDATE 语句中不能用
SET col = col这类“伪修改”，MySQL 会认为该列被修改而记录其新值，即使值未变
如何验证 MINIMAL 是否真正起效
最直接的方式是抓一条 UPDATE 的 binlog event 并 inspect 内容，而不是看文件大小——因为压缩、事务合并、其他 DML 混杂都会干扰体积判断。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
推荐步骤：
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析当前 binlog 文件（例如mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A 10 "UPDATE.*table_name"） - 观察输出中
### UPDATE ...后的### WHERE和### SET行数：若只有主键列 + 真正被改的列，则为MINIMAL；若出现大量### @N=...且 N 覆盖全部列，则仍是FULL - 注意：如果表没有主键，
WHERE部分会变成全字段比较（即所有列都出现在WHERE），此时即使设了MINIMAL也等效于FULL
MINIMAL 的代价和线上切换注意事项
它不是银弹。降低体积的同时，也削弱了 binlog 的可逆性和调试能力：
- 逻辑备份工具（如 mydumper）、部分 CDC 工具（如 Debezium 旧版本）依赖完整旧值做一致性校验，
MINIMAL可能触发报错或跳过事件 - 无法用 binlog 直接生成反向 SQL（比如把 UPDATE 变成反向 UPDATE），因为缺少未修改列的旧值
- 切换前务必在从库关闭复制（
STOP SLAVE），然后在主库设GLOBAL，再重启从库连接，否则可能因 event 解析失败导致复制中断 - 对历史 binlog 无效——已写入的 binlog 不会重写，调优效果只体现在新产生的日志中
真正影响体积的从来不是单个参数，而是表结构设计（有没有主键）、应用写法（是否批量更新大字段）、以及 binlog 生命周期管理。别只盯着 binlog_row_image，先确保每张表都有主键。
