必须选ROW以保障主从强一致及Binlog订阅、闪回、审计需求；STATEMENT因记录非确定性SQL易致主从不一致；MIXED为稳妥折中但不支持闪回。
直接结论：主从强一致或需用 Binlog 做数据订阅（如 Canal、Debezium）、闪回、审计，必须选 ROW；纯读写分离且 SQL 确保幂等、无非确定性函数，可考虑 STATEMENT；大多数业务系统默认用 MIXED 是稳妥折中方案，但注意它不解决闪回需求。
为什么 STATEMENT 模式会导致主从数据不一致
STATEMENT 记录的是原始 SQL 文本，靠从库重放同一语句来同步。但很多语句在不同时间、不同会话下执行结果不同：
-
NOW()、SYS DATE()、RAND()等函数每次执行返回值不同，主库插入INSERT INTO logs VALUES (NOW())，从库重放时写入的是重放时刻的时间，不是主库当时的时间 -
LIMIT无ORDER BY时，如DELETE FROM t LIMIT 10，主从因索引顺序或优化器路径差异可能删掉不同行 - 存储过程/触发器中含会话变量（如
@user_id）或LAST_INSERT_ID()，从库上下文缺失导致逻辑错乱 -
UUID()在主从上生成完全不同值，直接破坏业务唯一性约束
这些不是“偶尔出错”，而是 STATEMENT 模式的固有缺陷——它假设 SQL 是确定性的，而现实业务中大量使用非确定性表达。
ROW 模式下 binlog 体积暴增的真实场景
ROW 不记 SQL，只记每一行变更的前像（Before Image）和后像（After Image）。批量操作时日志量呈线性增长，不是按语句计，而是按行计：
- 一条
UPDATE product SET status = 2 WHERE category_id = 100修改 50 万行？binlog 就写 50 万条变更事件 -
ALTER TABLE类 DDL（如加字段），MySQL 实际是重建表，每行都触发一次 ROW 事件，日志瞬间膨胀数倍甚至数十倍 - 大字段（如
TEXT、BLOB）被修改时，整字段内容都会被完整记录进 binlog，IO 和网络带宽压力显著升高 - 主库高并发写入 + 大批量更新混合时，
binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count配置不当会加剧刷盘延迟，影响从库实时性
这不是理论风险——线上真实案例中，某次误执行的全表更新让 binlog 单小时增长 80GB，直接打满磁盘并拖慢主库响应。
MIXED 模式自动切换的边界在哪
MIXED 不是“智能判断”，而是 MySQL 内置了一张非确定性函数/语句黑名单，命中即切 ROW。常见触发条件包括：
- 显式调用：
UUID()、SYSDATE()、RAND()、USER()、CURRENT_USER() - 隐式依赖时间或会话状态的函数：
FOUND_ROWS()、ROW_COUNT()（在存储过程中使用时） - 某些 DDL 操作：
CREATE TABLE ... SELECT、含子查询的INSERT ... SELECT - 任何含
TRIGGER或STORED FUNCTION的写操作（即使函数本身确定）
注意：MIXED 切换是语句级的，不是事务级。一个事务里前几条用 STATEMENT，最后一条触发非确定性，后续所有语句都走 ROW，直到事务结束。它无法规避闪回、也无法保证跨语句的逻辑一致性（比如先查后更场景仍可能出问题）。
配置 binlog_format 后哪些操作立刻生效
SET GLOBAL binlog_format = 'ROW' 只影响新连接发起的写操作，已有连接不受影响。关键细节：
- 当前会话未提交的事务仍按旧格式记录，必须 COMMIT 或 ROLLBACK 后新建事务才生效
- 从库的
relay_log_info_repository = TABLE时，CHANGE MASTER TO后需重启 IO 线程才能识别新格式，否则复制可能中断 - MySQL 5.7.7+ 默认为
ROW，但升级后不会自动覆盖配置文件中的旧设置，my.cnf里的binlog-format项仍起效 - 云数据库（如阿里云 RDS、腾讯云 CDB）部分版本禁止动态修改，必须通过控制台或工单申请变更
真正容易被忽略的是：哪怕你设了 ROW，如果应用层用了 SELECT ... FOR UPDATE 加锁但没及时提交，binlog 中的锁信息不记录，从库无法感知阻塞关系——这不属于格式问题，但常被误判为 ROW 模式“失效”。
