ROW格式记录行变更而非SQL语句，精确保存每行数据的前后像，确保主从一致；STATEMENT因重放非确定性函数必然导致不一致；MIXED自动切换不可靠，生产环境应强制使用ROW并配置binlog_row_image=FULL。
ROW格式记录的是行变更，不是SQL语句
ROW模式下，binlog不保存任何SQL文本，只存「哪张表、哪几行、哪个字段、旧值是什么、新值是什么」。比如执行UPDATE user SET name = 'alice' WHERE id = 100，binlog里不会出现这行SQL，而是记录id=100这一行的完整前像（name='bob'）和后像（name='alice'）。
这种设计让主从复制完全脱离执行上下文：NOW()、UUID()、用户变量这些在STATEMENT里必然出错的东西，在ROW里根本不存在——因为不重放SQL，只应用数据快照。
- DDL（如
ALTER TABLE）仍以明文SQL记录，但所有DML都是二进制编码的行事件 - 必须加
--base64-output=decode-rows --verbose才能用mysqlbinlog看懂内容，否则全是base64乱码 - 无主键表在ROW模式下会触发全表扫描匹配条件行，极易造成从库延迟飙升
STATEMENT格式靠从库重放SQL，天然不可靠
STATEMENT把原始SQL原样写进binlog，从库拿到后重新执行一遍。表面省空间，实际埋雷：只要语句里带NOW()、UUID()、RAND()、USER()、LAST_INSERT_ID()，主从结果就一定不同。
这不是概率问题，是确定性失效。例如UPDATE order SET shipped_at = NOW() WHERE status = 'pending'，主库执行时刻是2026-11-04 12:20:00，等binlog传到从库再执行，时间可能已变成12:20:03——值对不上，业务逻辑就断了。
- 含
LIMIT但没ORDER BY的语句（如DELETE FROM log LIMIT 100），主从因索引顺序或优化器路径差异可能删掉完全不同的100行 - 存储过程中引用会话变量（如
@user_id），从库没有该会话上下文，直接执行失败或逻辑错乱 - MySQL 5.7+ 已默认禁用STATEMENT，设为该模式时会报警告：
[Warning] Statement may not be safe to log in statement format
MIXED模式自动切换不可信，别指望它兜底
MIXED看似聪明，其实是MySQL按内置规则表硬编码判断：遇到UUID()、触发器、存储过程、用户变量等就切ROW，其余走STATEMENT。但它完全不理解你的业务逻辑是否真安全。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
你写的UPDATE t SET x = @a := @a + 1会被识别为含用户变量，强制切ROW；但你可能只是本地调试，并不打算让从库执行它。反过来，某些自定义函数或新版函数MySQL识别不出，仍走STATEMENT，导致不一致却毫无提示。
- 切换逻辑不透明，排查主从不一致时得先确认当前语句实际用了哪种格式，徒增复杂度
- MySQL 8.0.26+ 已逐步弱化MIXED支持，官方文档倾向明确指定
binlog_format=ROW - MIXED不支持闪回类操作（如误删恢复），因为STATEMENT部分无法还原具体哪几行被改
选ROW不是妥协，是生产环境的底线要求
ROW日志体积大是事实，但代价换来的是一致性保障——这是金融、电商、支付等场景不可妥协的底线。一次全表UPDATE影响50万行，binlog确实会多写50万条事件；但比起主从数据错位、审计无法溯源、闪回失败，这点磁盘和带宽开销微不足道。
真正容易被忽略的是binlog_row_image配置。即使设了binlog_format=ROW，如果binlog_row_image是MINIMAL或NOBLOB，闪回或审计时可能拿不到完整前像，导致无法还原原始状态。生产环境必须配成binlog_row_image=FULL。
