绝大多数新项目应选ROW，因其复制精确、审计友好且兼容GTID；STATEMENT已不推荐，8.0中部分场景自动降级为ROW并可能因非确定函数报错；MIXED行为难预测，不建议生产使用。
直接选 ROW，除非你有明确且不可绕过的 STATEMENT 依赖
绝大多数新项目、升级中的生产环境，binlog_format = ROW 是唯一合理选择。它不是“折中”，而是当前 MySQL（5.7+ 尤其是 8.0）复制与审计事实上的安全基线。你不需要权衡“性能 vs 安全”——ROW 的安全性是刚性的，而所谓“性能损失”其实是可管理的工程问题，不是架构缺陷。
STATEMENT 模式下那些“报错但不解释”的错误，本质是 MySQL 在拒绝帮你埋雷
比如执行 INSERT INTO t SELECT ... FROM (SELECT NOW(), RAND() ...) AS tmp 时突然报 Statement is not safe to log in statement format，这不是配置没生效，是 MySQL 主动拦截了注定在从库产生偏差的操作。这类语句在 STATEMENT 下：
- NOW()、UUID()、USER() 等函数主从时间/上下文不同 → 结果不一致
- 自增 ID 插入顺序受事务并发影响 → 从库生成 ID 偏移
- 触发器或存储过程内部逻辑可能因临时表、会话变量等行为不可复现
ROW 绕过所有这些，直接记录“哪一行从 A 变成了 B”，无需解释上下文。
真正要调的不是 binlog_format，而是 sync_binlog 和磁盘水位
ROW 格式日志体积变大是确定性结果，但崩溃丢失风险和写入性能瓶颈其实由另一个参数控制：sync_binlog。
- 设为 0：依赖操作系统缓存刷盘 → 性能最好，但机器断电可能丢最近几秒事务
- 设为 1：每次事务提交都强制落盘 → 数据零丢失，但 IO 压力翻倍，尤其高并发小事务场景
- 推荐设为 100 或 1000：每 N 次事务刷一次盘，平衡明显，且崩溃最多丢 N 条事务
同时必须配 binlog_expire_logs_seconds（8.0.11+）或 expire_logs_days，否则单个 mysql-bin.000xxx 文件可能从 200MB 涨到 2GB+，不是日志没删，是真实写入量暴增。
别信 MIXED 能自动兜底，它的“自动”会让你更难排查
MIXED 表面省心，实际把判断权交给 MySQL 内部规则，而这些规则随版本更新变化（比如 8.0 对某些函数的判定更严格）。你遇到主从延迟突增、某条 UPDATE 同步失败、或者用 mysqlbinlog 解析时发现格式忽 Statement 忽 Row——大概率是 MIXED 在后台悄悄切换了模式。更麻烦的是：
- 复制过滤规则（如 replicate-do-table）在 ROW 和 STATEMENT 下行为不同，MIXED 会让过滤逻辑变得不可预测
- GTID 模式下 MIXED 可能触发隐式事务拆分，增加同步复杂度
线上环境宁可统一用 ROW，把“哪些语句不该跑”这件事交给应用层或 SQL 审计工具，而不是赌 MySQL 的自动判断。
最常被忽略的一点：ROW 格式下，没有主键的表会导致日志体积异常膨胀且复制效率暴跌——因为 MySQL 必须记录整行旧值才能定位变更行。检查所有被频繁更新的表是否都有主键，比纠结 binlog_format 本身重要得多。
